On Aug 28, 2006, at 6:10 PM, Bill Northcott wrote:
After R'ing TFM, I tried adding -single_module to LDFLAGS. That
worked, AFAICT, but I'm not sure this is the correct fix.
Sorry to be dense, but why is this a 'multi-module' problem? Ld is
spitting the dummy because of common symbols in the objects being
linked. I thought the normal practice on Darwin/MacOS X was to use
the -fno-common option on all compiles for code to be used in
shared objects. If this had been done, it might even have linked.
-single_module is the new hotness, everyone at Apple uses it because
"it loads faster" :-)
In this case, I doubt that it does load any faster though, most of
the load time will be spent looking for all the undefined symbols
that are there because of the missing -lstdc++ and -lgcc etc. Anyway,
I agree with you, -fno-common is a perfectly good way to solve the
common symbols in MH_DYLIB error, even if it is losing popularity.
I have not spent long on it but the only Darwin stuff seems to be
in Singular/configure.in. The other packages in the bundle seem to
inherit that configuration. The lines read:
ppcMac-darwin)
AC_CHECK_LIB(dl, dlopen)
if test "$ac_cv_lib_dl_dlopen" = yes; then
LD_DYN_FLAGS="-ldl -dynamic"
SFLAGS="-fpic -DPIC"
SLDFLAGS="-dynamic -twolevel_namespace -
weak_reference_mismatches weak -undefined dynamic_lookup"
LD=libtool
ac_lib_dl=yes
fi
;;
This seems to me to be a mis-configuration problem rather than just
a multi-module issue. Never mind the weird system names, just look
at some of the flags:
This does look likely to be the issue.
Peter
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Unix-porting mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/unix-porting/email@hidden
