Follow-up Comment #3, bug #29845 (project gnustep): No news, unfortunately. I'd be glad to provide a patch if I only knew what would be the correct fix... It seems that all platforms which use the GS_FAKE_MAIN hack are affected; on GNU/Linux you can reproduce the problem with
./configure --enable-fake-main LDFLAGS=-Wl,--no-undefined To your questions: > I'm guessing it's a build of a debian source package? That's right. > 1. Why is LDFLAGS set to "-Wl,-z,defs -Wl,--as-needed" ? The latter removes unnecessary dependencies. When you link -lfoo and -lbar, but you only need -lfoo, dpkg-shlibdeps will add an explicit package dependency on the package providing libfoo.so. -Wl,-z,defs is a safety check; it enables symbol resolution at build time, to ensure that all objects are linked against all libraries they use symbols from. Note that this is not a Debian invention; most binary-based distros (Fedora, Mandriva, etc.) use these flags for most packages, because this solves the following vital issues: 1) package foo *must* depend on all packages it needs 2) in the ideal case package foo should not depend on any packages it doesn't need, because this causes inconvenience for users and more importantly, complicates library transitions and the archive software (at least for Debian) > perhaps it's the cause of the problem? Absolutely. For the time being I workarounded the issue (to use only --as-needed on GNU/Hurd). > So the library is being built with the wrong objective-c library and/or incorrectly > configured gnustep-make. Yes, this is fixed in 1.20.0-1, but this problem is not the culprit here. > perhaps this bug report is obsolete No, it's not. _______________________________________________________ Reply to this item at: <http://savannah.gnu.org/bugs/?29845> _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ _______________________________________________ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep