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

Group
 
 

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

Submitter:  Yavor Doganov <yavor>
Submitted:  Mon 10 May 2010 08:27:13 AM UTC
   
 
Category:  Base/Foundation Severity:  3 - Normal
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

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

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-06-10 CaS Open/ClosedIn Test Closed
    2010-06-09 CaS StatusNone Fixed
        Open/ClosedOpen In Test

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code