My favorites | Sign in
Logo
Project Home
  
Downloads
  
Wiki
  
Issues
  
Source
    
New issue | Search
for
| Advanced search | Search tips
Issue 32: Support non-Apple systems with GnuStep
3 people starred this issue and may be notified of changes. Back to list
Status:  Accepted
Owner:  alex.blewitt
Cc:  rrusaw
Type-Enhancement
Priority-Medium


Sign in to add a comment
 
Reported by alex.blewitt, Jul 10, 2009 
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.
Comment 1 by alex.blewitt, Jul 17, 2009 
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?
Comment 2 by rrusaw, Jul 19, 2009 
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
Comment 3 by alex.blewitt, Jul 20, 2009 
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 ?
Comment 4 by rrusaw, Jul 20, 2009 
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.
Comment 5 by alex.blewitt, Jul 21, 2009 
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.
Comment 6 by eric.yam@am.sony.com, Oct 12, 2009 
Alex and Ryan, is there a version of non-Apple objectivEClipe with GNUStep I could 
help to test?
Comment 7 by alex.blewitt, Oct 12, 2009 
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.
Comment 8 by eric.yam@am.sony.com, Nov 20, 2009 
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.
Comment 9 by berger.max, Nov 25, 2009 
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
Comment 10 by alex.blewitt, Dec 01, 2009 
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)
Comment 11 by eric.yam@am.sony.com, Dec 01, 2009 
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?
Comment 12 by berger.max, Dec 11, 2009 
Hi *,

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

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

Max
Sign in to add a comment

Hosted by Google Code