[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Darwin 6.8: linking of base and gui to GNU-libobjc failed
From: |
Lars Sonchocky-Helldorf |
Subject: |
Darwin 6.8: linking of base and gui to GNU-libobjc failed |
Date: |
Sat, 28 Feb 2004 00:19:53 +0100 |
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 ...
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Darwin 6.8: linking of base and gui to GNU-libobjc failed,
Lars Sonchocky-Helldorf <=