Problems building GNUstep-base on Darwin x86 using gcc 4.0 (experimental)

[Lars Sonchocky-Helldorf]

The problem:
===========

linking of libgnustep-base fails because the gnu-objc-runtime is not 
found by gnustep-make


My setup:
=========

localhost:~/GNUstep-Darwin/core/base/Source lars$ uname -a
Darwin localhost 7.2.1 Darwin Kernel Version 7.2.1: Wed Jul 14 03:00:02 
PDT 2004; root:tmp/xnu-7.2.1-1-root.obj/RELEASE_I386  x86 i386

I have some additional libraries installed through DarwinPorts (a 
portage system for (Open)Darwin (and others)) in lib/ of /opt/local/ 
which is the default location of DarwinPorts.

I use a self build snapshot of gcc trunk which I also installed in 
/opt/local/ (I did this because of the gnu-objc-runtime it build now):

localhost:~/GNUstep-Darwin/core/base/Source lars$ /opt/local/bin/gcc -v
Reading specs from 
/opt/local/bin/../lib/gcc/i686-apple-darwin7.2.1/4.0.0/specs
Configured with: ../gcc-4.0-20040919/configure --prefix=/opt/local/
Thread model: posix
gcc version 4.0.0 20040919 (experimental)

during building gcc the gnu-objc-runtime got installed in 
/opt/local/lib/ (like every other additional library):

localhost:~/GNUstep-Darwin/core/base/Source lars$ locate libobjc-gnu
.
.
.
/opt/local/lib/libobjc-gnu.1.0.0.dylib
/opt/local/lib/libobjc-gnu.1.dylib
/opt/local/lib/libobjc-gnu.a
/opt/local/lib/libobjc-gnu.dylib
/opt/local/lib/libobjc-gnu.la


What happens:
=============

gnustep-make tries to link libgnustep-base as follows:

/usr/bin/libtool -noall_load -read_only_relocs warning -flat_namespace 
-undefined warning -single_module  -dynamic  -current_version 1.10.0 
-install_name libgnustep-base.dylib.1.10         -o 
shared_obj/libgnustep-base.dylib.1.10.0  shared_obj/GSCompatibility.o
.
.
.
 shared_obj/NSNumber12.o Additions/shared_obj/subproject.o  
-L./shared_obj -L/opt/local/GNUstep/System/Library/Libraries/ -ldl -lz 
-lxml2 -lz -liconv -lm   ; (cd ./shared_obj; rm -f 
libgnustep-base.dylib; if [ "libgnustep-base.dylib.1.10" != 
"libgnustep-base.dylib.1.10.0" ]; then rm -f 
libgnustep-base.dylib.1.10; ln -s libgnustep-base.dylib.1.10.0 
libgnustep-base.dylib.1.10; fi; ln -s libgnustep-base.dylib.1.10.0 
libgnustep-base.dylib)

which results in:

/usr/bin/ld: for architecture i386
/usr/bin/ld: warning undefined symbols:
___objc_exec_class
_objc_get_class
_objc_msg_lookup
... all other objc symbols


Workaround:
===========

Using:

./configure --disable-do CC='/opt/local/bin/gcc' 
LDFLAGS='-L/opt/local/lib -lobjc-gnu'

instead of just:

./configure --disable-do CC='/opt/local/bin/gcc'

kind of works. Now I only get:

/usr/bin/ld: for architecture i386
/usr/bin/ld: warning undefined symbols:
___udivdi3
___umoddi3
___fixunsdfdi
___fixunssfdi
_gnustep_base_user_main

which is a different problem.


Subsequent problems:
====================

But later in the build process (first time during linking autogsdoc 
using gcc) -lobjc from gnustep-make and -lobjc-gnu from LDFLAGS collide:

/opt/local/bin/gcc        -o shared_obj/autogsdoc \
        ./shared_obj/autogsdoc.o ./shared_obj/AGSParser.o 
./shared_obj/AGSOutput.o ./shared_obj/AGSIndex.o ./shared_obj/AGSHtml.o 
\
         -L../Source/./shared_obj 
-L/opt/local/GNUstep/System/Library/Libraries/ -L/opt/local/lib 
-lgnustep-base -lobjc -ldl -lobjc-gnu -lz -lxml2 -lz -liconv -lm -lm
/usr/bin/ld: warning suggest use of -bind_at_load, as lazy binding may 
result in errors or different symbols being used
symbol __objcInit used from dynamic library 
/opt/local/lib/libobjc-gnu.dylib(linking.o) not from earlier dynamic 
library /usr/lib/libobjc.A.dylib(single module)
symbol _object_copy used from dynamic library 
/opt/local/lib/libobjc-gnu.dylib(objects.o) not from earlier dynamic 
library /usr/lib/libobjc.A.dylib(single module)
symbol _object_dispose used from dynamic library 
/opt/local/lib/libobjc-gnu.dylib(objects.o) not from earlier dynamic 
library /usr/lib/libobjc.A.dylib(single module)

I don't know if gcc is clever enough to pass -lobjc-gnu to ld itself if 
it recognizes that the gnu-runtime is used, but that would require 
-fgnu-runtime to be present in the command line to give gcc at least a 
chance to "do the right thing (TM)".

the same holds true for all the other tools (cvtenc, gdnc, defaults, 
plmerge, plparse, sfparse, pldes, plser, pl2link, xmlparse, gdomap ...)


Solution:
=========

Fiddling around with LDFLAGS can IMHO only be a timed workaround to 
realize what gnustep-make should manage in the future. Sadly I am not 
familiar with the innards of gnustep-make and so I am unable what would 
be the right thing to do. I think it would be good if configure could 
recognize the combination of Darwin, the library-combo gnu-gnu-gnu and 
the use of (an alternate) gcc and add the appropriate stuff to 
ADDITIONAL_LIB_DIRS and ADDITIONAL_OBJC_LIBS.

Is that possible?


That was a long mail. Thanks for your patience and reading it to the 
end.

regards, Lars