Darwin 6.8: linking of base and gui to GNU-libobjc failed

[Lars Sonchocky-Helldorf]

Hi,

here is one more of my stupid question with which I already bugged 
GNUstep people with at FOSDEM.

Trying to build (and use!) GNUstep on Mac OS X 10.2.8/Darwin 6.8 I 
ended up with base and gui libraries not linked to libobjc according to 
'otool -L':

[Lars-Sonchocky-Helldorfs-Computer:GNUstep-Darwin/core/base] lars% 
otool -L 
/opt/local/GNUstep/System/Library/Libraries/libgnustep-base.dylib
/opt/local/GNUstep/System/Library/Libraries/libgnustep-base.dylib:
        libgnustep-base.dylib.1 (compatibility version 0.0.0, current 
version 1.9.0)
        /opt/local/lib/libiconv.2.dylib (compatibility version 5.0.0, 
current version 5.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, 
current version 63.0.0)
        /usr/lib/libz.1.1.3.dylib (compatibility version 1.0.0, current 
version 1.1.3)
[Lars-Sonchocky-Helldorfs-Computer:GNUstep-Darwin/core/base] lars%

the link command used to link the library during 'make messages=yes' 
was:

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

which resulted in:

ld: for architecture ppc
ld: warning undefined symbols:
___objc_exec_class
_objc_get_class
_objc_msg_lookup
_objc_alignof_type
_objc_calloc
_objc_get_type_qualifiers
_objc_sizeof_type
_objc_skip_argspec
_objc_skip_type_qualifiers
_objc_skip_typespec
_sel_get_type
_sel_types_match
_objc_msg_lookup_super
_sel_get_name
___objc_class_name_Protocol
___udivdi3
___umoddi3
_objc_free
_objc_lookup_class
_objc_malloc
_objc_layout_structure
_objc_layout_structure_get_info
_objc_layout_structure_next_member
_objc_next_class
___objc_class_name_Object
_class_get_instance_method
_sel_register_typed_name
_sel_get_any_typed_uid
_sel_get_typed_uid
_sel_register_name
_class_get_class_method
_get_imp
_sel_get_any_uid
_objc_condition_allocate
_objc_condition_broadcast
_objc_condition_deallocate
_objc_condition_wait
_objc_mutex_allocate
_objc_mutex_deallocate
_objc_mutex_lock
_objc_mutex_trylock
_objc_mutex_unlock
_objc_thread_id
___cmpdi2
___fixdfdi
___fixsfdi
___fixunsdfdi
___fixunssfdi
___floatdidf
___floatdisf
___objc_responds_to
_class_pose_as
_objc_get_stream_class_version
_objc_msg_sendv
_objc_verror
_gnustep_base_user_main
_objc_set_thread_callback
_objc_thread_add
_objc_thread_detach
_objc_thread_exit
_objc_thread_get_data
_objc_thread_get_priority
_objc_thread_remove
_objc_thread_set_data
_objc_thread_set_priority
_objc_realloc
__objc_load_callback
___objc_resolve_class_links
_class_add_method_list
_objc_aligned_size
_search_for_method_in_list

however in my desperate mood I 'cd'ed into the Source dir and issued 
the link command manually after adding a ' -lobjc' to it:

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

now the linker reacted with a different message which also leaves me 
baffled:

ld: for architecture ppc
ld: common symbols not allowed with MH_DYLIB output format with the 
-multi_module option
/opt/local/lib/libobjc.dylib(init.o) definition of common 
__objc_load_callback (size 4)
/usr/bin/libtool: internal link edit command failed
if: Expression Syntax.

I did not see any -multi_module option in the issued command :-\. And 
since it is possible that there is a grammatical error in the error 
message so that it should read instead:

ld: common symbols not allowed with MH_DYLIB output, format with the 
-multi_module option

I also tried to add this option: same error message as before.

btw.:

To build GNUstep I used a gcc3.3.3 prerelease. I installed it into 
/opt/local/ (this is the default location for the DarwinPorts. So I 
just used it too.). GCCs libobjc was build too (automatically) and 
ended up in: /opt/local/lib . GNUstep was configured and made like:

cd /Volumes/Data/Projekte/GNUstep-Darwin/core
cd make/
./configure --with-library-combo=gnu-gnu-gnu 
--prefix=/opt/local/GNUstep CC='/opt/local/bin/gcc' 
CPPFLAGS='-I/opt/local/include' LDFLAGS='-L/opt/local/lib'
make messages=yes
make install messages=yes
source /opt/local/GNUstep/System/Makefiles/GNUstep.csh
cd ../base/
./configure --disable-do --disable-xml CC='/opt/local/bin/gcc' 
CPPFLAGS='-I/opt/local/include' LDFLAGS='-L/opt/local/lib'
make messages=yes
make install messages=yes
cd ../gui/
./configure --disable-gsnd CC='/opt/local/bin/gcc' 
CPPFLAGS='-I/opt/local/include' LDFLAGS='-L/opt/local/lib'
make messages=yes
make install messages=yes
cd ../back/
./configure  --enable-graphics=xlib CC='/opt/local/bin/gcc' 
CPPFLAGS='-I/opt/local/include' LDFLAGS='-L/opt/local/lib'
make messages=yes
make install messages=yes

Btw.: I also have the config.log files handy if this helps to nail down 
the case. I just did not want to post them to the list since they are 
pretty large.

Thanks, Lars

P.S.: I did some further research and found the following:

core/base/Examples/shared_obj/dictionary runs even with the symbolic 
link libobjc.dylib removed and libojc.a and libobjc.la renamed to 
libobjc_off.a and libobjc_off.la:

[Lars-Sonchocky-Helldorfs-Computer:base/Examples/obj] lars% 
./dictionary        2004-02-28 00:02:33.213 dictionary[1289] There are 
6 elements stored in the dictionary
2004-02-28 00:02:33.331 dictionary[1289] Element 3 is stored at "three"
2004-02-28 00:02:33.333 dictionary[1289] Removing element stored at 
"three"
2004-02-28 00:02:33.335 dictionary[1289] Now there are 5 elements 
stored in the dictionary
[Lars-Sonchocky-Helldorfs-Computer:base/Examples/obj] lars%

[Lars-Sonchocky-Helldorfs-Computer:/opt/local/lib] lars% ls -al libobjc*
-rw-r--r--  1 lars  admin  608216 Feb  6 03:00 libobjc_off.a
-rwxr-xr-x  1 lars  admin     685 Feb  6 03:00 libobjc_off.la
[Lars-Sonchocky-Helldorfs-Computer:/opt/local/lib] lars%

Strange, somehow ...