[bug #29845] FTBFS on GNU/Hurd with -Wl,--no-undefined
Follow-up Comment #8, bug #29845 (project gnustep): Seems to be working fine. Thank you very much. ___ 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
[bug #29845] FTBFS on GNU/Hurd with -Wl,--no-undefined
Update of bug #29845 (project gnustep): Open/Closed: In Test = Closed ___ 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
[bug #29845] FTBFS on GNU/Hurd with -Wl,--no-undefined
Follow-up Comment #2, bug #29845 (project gnustep): Any news on this? It would be nice to get a fix into a 1.20.1 release. Also, I looked at the URL https://buildd.debian.org/fetch.cgi?pkg=gnustep-basearch=hurd-i386ver=1.19.3-2stamp=1273445079file=logas=raw I can't claim to fully understand this log, but I'm guessing it's a build of a debian source package? A few queries/observations... 1. Why is LDFLAGS set to -Wl,-z,defs -Wl,--as-needed ? I don't know what this does ... it seems unlikely (since I guess these flags do no harm on other systems) but perhaps it's the cause of the problem? It's a natural suspect since the flags are for the linker and the problem is a linker issue (the linker ought to be expecting gnustep_base_user_main to be undefined, not complaining about it). 2. The base configure log says: Your gnustep-make is configured to use native objc exceptions, but the objc runtime does not appear to support setting an uncaught exception handler. This means that any uncaught exception will cause a program to abort immediately. Consider reconfiguring gnustep-make or updating libobjc to fix this. So the library is being built with the wrong objective-c library and/or incorrectly configured gnustep-make. That suggests that the packages or package dependencies are faulty. I can't see how this could have any effect on the linking issue, but it looks like a package problem. Of course, this is an old version of GNUstep anyway ... so perhaps this bug report is obsolete and should simply be closed? ___ 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
[bug #29845] FTBFS on GNU/Hurd with -Wl,--no-undefined
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
[bug #29845] FTBFS on GNU/Hurd with -Wl,--no-undefined
Follow-up Comment #4, bug #29845 (project gnustep): Ah ... so '-Wl,-z,defs -Wl,--as-needed' has a similar effect to '-Wl,--no-undefined' In that case this is really not a bug ... the linker flags are telling the link to fail since the fake main mechanism *requires* the gnustep_base_user_main() function to be undefined as it is supplied by the program which is using gnsutep. ie. your program implements gnustep_base_user_main() and the base library calls the method in your program from the main() function in NSProcessInfo.m So this is more a package bug (building base with illegal linker flags), than a gnustep bug, but I guess either way we want to fix it somehow. So ... there are two obvious options: 1. change the package script to change the linker flags ... but as they do something useful (as well as breaking things), that's not ideal. 2. add hurd support to avoid the need for fake-main The reason for the existence of fake-main is to allow the NSProcessInfo class to be properly initialized with the process arguments and environment. On many platforms we can get that information from the /proc filesystem or by some other system specific mechanism. On platforms where there is no known mechanism to get that information, we have to use the argc, argv, and envp arguments to main() (which is what the fake-main does for us). If there's a hurd specific way to obtain that info, we could change the configure.ac to detect its presence and add code to use it instead of fake-main. Do you know of a way to do it? I suppose another option is just to change the makefile to filter out the linker flags which cause the trouble, but that's not much better than changing the package build script to refrain from using the flags. ___ 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
[bug #29845] FTBFS on GNU/Hurd with -Wl,--no-undefined
Follow-up Comment #5, bug #29845 (project gnustep): Ah ... so '-Wl,-z,defs -Wl,--as-needed' has a similar effect to '-Wl,--no-undefined' Almost; -Wl,-z,defs is another way of writing -Wl,--no-undefined. the fake main mechanism requires the gnustep_base_user_main() function to be undefined as it is supplied by the program which is using gnsutep. Thanks... I never actually fully understood the fake-main thingy :-( So it's not a bug, I agree. So this is more a package bug (building base with illegal linker flags) (You mean invalid, illegal is something different and its use in this context is discourged by the GNU Coding Standards.) Yes, I agree the value of LDFLAGS is invalid for this platform, and it's a Debian packaging bug for defining it. If there's a hurd specific way to obtain that info, we could change the configure.ac to detect its presence and add code to use it instead of fake-main. Do you know of a way to do it? IIRC one or two years ago there was a Hurd GSoC project for implementing a GNU/Linux-compatible procfs translator. AFAICS now, the code has been merged into the Hurd repository and is available in the Debian hurd(-dev) package. So my wild guess is that /proc on GNU/Hurd is not mounted by default, which is why the configure check fails. I can use --enable-procfs when configuring gnustep-base on this platform, but I have to recheck with the Hurd people if/how it is guaranteed to have /proc on a live user GNU/Hurd system, otherwise things may break at runtime. Many thanks for enlightening me. I suggest to close this bug; if it turns out there are other related issues I'll follow up accordingly. ___ 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
[bug #29845] FTBFS on GNU/Hurd with -Wl,--no-undefined
Follow-up Comment #6, bug #29845 (project gnustep): seems like you could declare gnustep_base_user_main with __attribute__((weak)) which should allow it to continue building with -Wl,-z,defs ___ 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
[bug #29845] FTBFS on GNU/Hurd with -Wl,--no-undefined
Update of bug #29845 (project gnustep): Status:None = Fixed Open/Closed:Open = In Test ___ Follow-up Comment #7: Great idea about making gnustep_base_user_main 'weak' It's never quite that simple, but with some other tweaking I think I've got the code to a state where we can use fake-main *and* -Wl,--no-undefined Changes now in svn trunk. Please give it a go and let me know. ___ 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
[bug #29845] FTBFS on GNU/Hurd with -Wl,--no-undefined
Follow-up Comment #1, bug #29845 (project gnustep): I don't have Hurd, but if you can supply a patch against the gnustep svn (or the current release) I can apply it so it gets into the next bugfix release ... assuming that the problem is with base itsself (if this is a linker flags issue, you would presumably need to patch gnustep-make instead). ___ 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
[bug #29845] FTBFS on GNU/Hurd with -Wl,--no-undefined
URL: http://savannah.gnu.org/bugs/?29845 Summary: FTBFS on GNU/Hurd with -Wl,--no-undefined Project: GNUstep Submitted by: yavor Submitted on: Mon May 10 11:27:13 2010 Category: Base/Foundation Severity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any ___ Details: Building gnustep-base/1.19.3 on GNU/Hurd with LDFLAGS set to -Wl,-z,defs -Wl,--as-needed fails during linking with: /build/buildd-gnustep-base_1.19.3-2-hurd-i386-fh_Ygd/gnustep-base-1.19.3/Source/NSProcessInfo.m:921: undefined reference to `gnustep_base_user_main' Relevant portions from `configure' output: checking procfs.h usability... no checking procfs.h presence... no checking for procfs.h... no checking kernel support for /proc filesystem... no checking support for /proc psinfo struct... no checking link to exe of process in /proc... no checking /proc/25986/cmdline terminated by nul... no checking for kvm_getenvv in -lkvm... no checking use of pass-through arguments... no checking use of fake-main definition... yes Toolchain packages used: libc0.3-dev_2.10.2-7 hurd-dev_20090404-2 gnumach-dev_2:1.3.99.dfsg.git20091128-1 gcc-4.4_4.4.4-1 binutils_2.20.1-9 Full build log: https://buildd.debian.org/fetch.cgi?pkg=gnustep-basearch=hurd-i386ver=1.19.3-2stamp=1273445079file=logas=raw ___ 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
