Support non-Apple systems with GnuStep

[GoogleCodeExporter]

At the moment, the supported goal has been to get 
Mac support working. However, there are relatively 
few things which need Apple systems. If we can get a 
good story about testing on Linux with GnuStep, then 
we should do so. 

Issues: 

* The ObjcCompiler and ObjcLinker are really 
AppleCompiler and AppleLinker. The Apple linker 
provides -framework support, and the compiler 
provides -arch, which are not supported on other 
platforms. 

* the update site claims to be macos only 

* handling of special framework includes like 
#import<A/B.h> is Apple only

* some objc features may not be present (eg 
properties)

* the new wizard presuggests the objc toolchain, 
which makes sense on macs but not elsewhere. 

* there is an interesting question on using non-Apple 
systems to compile against Apple SDKs. The main 
stumbling block here is the fact that any framework 
header imported will no doubt refer to other 
framework headers using the shorthand framework 
concept. And whilst we can probably handle this in 
CDT for the editor but the underlying gcc might need 
some help. Either that, or a tool post processes the 
SDK to arrange a dir such that A/B.h exists.   

Original issue reported on code.google.com by alex.ble...@gmail.com on 10 Jul 2009 at 11:42

[GoogleCodeExporter]

Ryan, how does GNUStep lay out its Foundation libraries? Is there a 
/usr/lib/objc which contains 
Foundation/Foundation.h ? If so, what do you need to pass to the linker instead 
of -framework to make it 
happen, and what library search paths do you need to add to make the include 
work?

Original comment by alex.ble...@gmail.com on 17 Jul 2009 at 8:51

[GoogleCodeExporter]

There is a /usr/include/GNUStep that includes Foundation/Foundation.h.

There is also a hierachy of files under /usr/share/GNUStep/  and one under
/usr/lib/GNUStep/. The later has several symlinks back to the former. 

ie. 

ryanru@PrinceHumperdinck:~$ ls -al
/usr/lib/GNUstep/Frameworks/Addresses.framework/Versions/Current/
total 188
drwxr-xr-x 2 root root     74 2009-06-14 15:09 .
drwxr-xr-x 3 root root     28 2009-06-14 15:09 ..
lrwxrwxrwx 1 root root     21 2009-06-14 15:09 libAddresses.so.0 -> 
libAddresses.so.0.0.1
-rw-r--r-- 1 root root 189692 2008-07-06 07:52 libAddresses.so.0.0.1
lrwxrwxrwx 1 root root     73 2009-06-14 15:09 Resources ->
../../../../../../share/GNUstep/Frameworks/Addresses.framework/Versions/0

Perhaps the easiest way would be to leverage the GNUStep makefile system.

http://www.gnustep.org/resources/documentation/make_toc.html

Original comment by rrusaw@gmail.com on 20 Jul 2009 at 2:56

[GoogleCodeExporter]

OK, so there's 

/usr/include/GNUStep/Foundation/Foundation.h
/usr/include/GNUStep/AppKit/AppKit.h 

etc? Then we should be able to support GNUStep easily enough if we just have -I 
/usr/include/GNUStep (-
eye), right?

How does the linker/runtime know where the libAddresses.so is? Presumably, the 
command line (if the 
Addresses framerwork is selected) just ends up with -l addresses (-ell) on the 
command line, but how does 
it then know which directories to search? Or is there a 
/usr/lib/include/libAddresses.so -> 
/usr/lib/GNUStep/Frameworks/Addresses.framework/Versions/Current/libaddresses.so
 ?

Original comment by alex.ble...@gmail.com on 20 Jul 2009 at 8:39

[GoogleCodeExporter]

1. Yes. 

ryannru@PrinceHumperdinck:~/Desktop$ ls /usr/include/GNUstep/
AppKit/               Foundation/           gnustep/             
GormObjCHeaderParser/ InterfaceBuilder/     TalkSoupBundles/
Cocoa/                Frameworks/           GNUstepBase/          GormPrefs/    

   Operation/            WizardKit/
Cynthiune/            FSNode/               GNUstepGUI/           
HighlighterKit/   
   ProjectCenter/        
DBKit/                GNUMail/              GormCore/             Inspector/    

   Renaissance/ 

2. Just a symlink to the real library. 

ryannru@PrinceHumperdinck:~/Desktop$ ls -al /usr/lib/libAddresses.so.0.0.1 
lrwxrwxrwx 1 root root 77 2009-06-14 15:09 /usr/lib/libAddresses.so.0.0.1 ->
GNUstep/Frameworks/Addresses.framework/Versions/Current/libAddresses.so.0.0.1

ryannru@PrinceHumperdinck:~/Desktop$ ldd /usr/bin/GNUMail 
    linux-gate.so.1 =>  (0xb7f4b000)
    libGNUMail.so.1 => /usr/lib/libGNUMail.so.1 (0xb7dd0000)
    libPantomime.so.1.2 => /usr/lib/libPantomime.so.1.2 (0xb7d29000)
    libAddresses.so.0 => /usr/lib/libAddresses.so.0 (0xb7cf9000)
    libAddressView.so.0 => /usr/lib/libAddressView.so.0 (0xb7cc9000)
    libgnustep-gui.so.0.14 => /usr/lib/libgnustep-gui.so.0.14 (0xb78cb000)
    libgnustep-base.so.1.16 => /usr/lib/libgnustep-base.so.1.16 (0xb74c3000)
    libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb74aa000)
    libobjc.so.2 => /usr/lib/libobjc.so.2 (0xb748f000)
    libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7469000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb745a000)
    libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb72f7000)
    libssl.so.0.9.8 => /lib/i686/cmov/libssl.so.0.9.8 (0xb72b0000)
    libcrypto.so.0.9.8 => /lib/i686/cmov/libcrypto.so.0.9.8 (0xb7163000)
    libaudiofile.so.0 => /usr/lib/libaudiofile.so.0 (0xb713e000)
    libaspell.so.15 => /usr/lib/libaspell.so.15 (0xb70a2000)
    libgif.so.4 => /usr/lib/libgif.so.4 (0xb7099000)
    libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7073000)
    libtiff.so.4 => /usr/lib/libtiff.so.4 (0xb701c000)
    libz.so.1 => /lib/libz.so.1 (0xb7006000)
    libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb6fe6000)
    libdns_sd.so.1 => /usr/lib/libdns_sd.so.1 (0xb6fdd000)
    libgnutls.so.26 => /usr/lib/libgnutls.so.26 (0xb6f40000)
    libxslt.so.1 => /usr/lib/libxslt.so.1 (0xb6f08000)
    libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb6dcc000)
    libffi.so.5 => /usr/lib/libffi.so.5 (0xb6dc4000)
    libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0xb6dab000)
    libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb6da7000)
    /lib/ld-linux.so.2 (0xb7f4c000)
    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb6cb7000)
    libavahi-common.so.3 => /usr/lib/libavahi-common.so.3 (0xb6cab000)
    libavahi-client.so.3 => /usr/lib/libavahi-client.so.3 (0xb6c9a000)
    libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0xb6c88000)
    libgcrypt.so.11 => /lib/libgcrypt.so.11 (0xb6c1f000)
    libdbus-1.so.3 => /lib/libdbus-1.so.3 (0xb6be6000)
    libgpg-error.so.0 => /lib/libgpg-error.so.0 (0xb6be2000)

It looks like they are just pass in the library names to ld, and they are 
resolved
normally via the standard ld.so.1 LD_LIBRARY_PATH resolution.

Original comment by rrusaw@gmail.com on 21 Jul 2009 at 2:45

[GoogleCodeExporter]

OK, it sounds like it should be easy enough to use this with the standard GCC 
compiler then. 

Right now, we explicitly select the ObjC linker as part of the setup process. 
This adds the -frameworks 
option for the linker, which is a bit manual.

If we can externalise out that into a general configuration variable for 
FRAMEWORKS, and then have a 
process that maps these to -framework on Mac and -l on GNUStep systems, we 
should be good to go.

We can probably do the same for PLATFORMs, but I believe that GNUStep doesn't 
provide for that? Basically, 
instead of /usr/lib/GNUStep, it would refer to /usr/old/GNUStep or some such? I 
guess we need to provide 
a preference pane for configuring where GNUStep is located in any case, just in 
case it's somewhere else.

Original comment by alex.ble...@gmail.com on 21 Jul 2009 at 7:56

[GoogleCodeExporter]

Alex and Ryan, is there a version of non-Apple objectivEClipe with GNUStep I 
could 
help to test?

Original comment by eric.yam@am.sony.com on 12 Oct 2009 at 9:15

[GoogleCodeExporter]

Hi Eric

I really need to release a new build with the mac-specific restrictions so that 
it's more generally 
applicable. I've been caught up with other projects but want to devote more 
time to this soon. 

Original comment by alex.ble...@gmail.com on 12 Oct 2009 at 11:12

[GoogleCodeExporter]

Alex and Ryan,
I have objectivEClipe working on Linux.  I just changed the library path and 
header 
path point to GNUstep.  It can build and run objective c projects.  But I need 
help 
with gdb debugger.  It started gdb->gdb/mi but I could not do single step.  GDB 
works in command line.  The eclipse console shows:
.gdbinit: No such file or directory
Stopped due to shared library even
[0] cancel
[1] all
[2] -[NSOperation main] at NSOperation.m:101
[3] -[MSThread main] at NSThread.m:736
[4] main at ../src/ImageViewe.m: 200
>

The ImageViewer.m line 200 is my main.  I tried different configurations, it 
still 
stopped at the same point.

Original comment by eric.yam@am.sony.com on 20 Nov 2009 at 6:17

[GoogleCodeExporter]

Eric,

great news! Could you provide a patch so
- I can test this
- the devs can probably add Linux support to the mainstream distribution!

Thanks

Max

Original comment by berger....@gmail.com on 25 Nov 2009 at 9:52

[GoogleCodeExporter]

Eric/Max,

Thanks for the comments. I need to fix the automated build and commit a few 
things before I can look at this 
- not sure about the gdb issue. When we've got 0.3 out with cross-platform 
support, perhaps we can dig into 
it then.

(Just wanted to ping this bug so you're aware it's still a work in progress)

Original comment by alex.ble...@gmail.com on 1 Dec 2009 at 7:44

[GoogleCodeExporter]

Alex and Max,
I got the gdb issue figured out.  I just needed .gdbinit point to the source 
code.

Max,
Can I email the patch to you for testing?

Original comment by eric.yam@am.sony.com on 1 Dec 2009 at 8:14

[GoogleCodeExporter]

Hi *,

cloned the project at github:
http://github.com/maxberger/objectiveclipse

tried to incorportate eric's patch (still not 100% working)

Max

Original comment by berger....@gmail.com on 11 Dec 2009 at 1:54

[GoogleCodeExporter]

I've merged Max's changes into the repository, and removed the 
platform-specific features that prevented the 
feature from installing on non-mac platforms. It hasn't been tested on anything 
other than OSX.

Original comment by alex.ble...@gmail.com on 2 Jun 2010 at 10:50

• Changed state: Fixed