bugGNUstep - Bugs: bug #29845, FTBFS on GNU/Hurd with...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #29845: FTBFS on GNU/Hurd with -Wl,--no-undefined

Submitted by:  Yavor Doganov <yavor>
Submitted on:  Mon 10 May 2010 08:27:13 AM UTC  
 
Category: Base/FoundationSeverity: 3 - Normal
Item Group: BugStatus: Fixed
Privacy: PublicAssigned to: None
Open/Closed: Closed

(Jump to the original submission Jump to the original submission)

Thu 10 Jun 2010 07:15:17 AM UTC, comment #8:

Seems to be working fine. Thank you very much.

Yavor Doganov <yavor>
Wed 09 Jun 2010 03:06:22 PM UTC, 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.

Richard Frith-Macdonald <CaS>
Project Member
Wed 09 Jun 2010 11:39:34 AM UTC, comment #6:

seems like you could declare gnustep_base_user_main with _attribute_((weak)) which should allow it to continue building with -Wl,-z,defs

matt rice <ratmice>
Project Member
Wed 09 Jun 2010 11:16:46 AM UTC, comment #5:

> 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.

Yavor Doganov <yavor>
Wed 09 Jun 2010 10:19:49 AM UTC, comment #4:

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.

Richard Frith-Macdonald <CaS>
Project Member
Wed 09 Jun 2010 09:07:11 AM UTC, comment #3:

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.

Yavor Doganov <yavor>
Wed 09 Jun 2010 08:39:10 AM UTC, comment #2:

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-base&arch=hurd-i386&ver=1.19.3-2&stamp=1273445079&file=log&as=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?

Richard Frith-Macdonald <CaS>
Project Member
Sat 29 May 2010 07:42:44 AM UTC, comment #1:

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).

Richard Frith-Macdonald <CaS>
Project Member
Mon 10 May 2010 08:27:13 AM UTC, original submission:

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-base&arch=hurd-i386&ver=1.19.3-2&stamp=1273445079&file=log&as=raw

Yavor Doganov <yavor>

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by ratmice (Posted a comment)
  • -unavailable- added by CaS (Posted a comment)
  • -unavailable- added by yavor (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 10 Jun 2010 08:01:34 AM UTCCaSOpen/ClosedIn Test=>Closed
    Wed 09 Jun 2010 03:06:22 PM UTCCaSStatusNone=>Fixed
      Open/ClosedOpen=>In Test

    Back to the top


    Powered by Savane 3.1-cleanup1