bugGNUstep - Bugs: bug #23876, gnustep-base does not build in a...

Group
 
 

bug #23876: gnustep-base does not build in a chrooted environment

Submitter:  Funda Wang <fundawang>
Submitted:  Fri 18 Jul 2008 02:23:54 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

Wed 20 Aug 2008 11:26:32 AM UTC, comment #13: 

Thanks ... patch applied ... fixed in subversion now.

Richard Frith-Macdonald <CaS>
Group Member
Wed 20 Aug 2008 11:20:46 AM UTC, comment #12: 

yes it builds correctly in a chrooted environment. Thanks.

Funda Wang <fundawang>
Wed 20 Aug 2008 09:30:07 AM UTC, comment #11: 

I just tried in a pbuilder chroot (which mounts /proc) -- the `mount' command outputs nothing.

The attached trivial patch should be equally reliable and should DTRT in such chroots.  Funda Wang, does it work for you if you apply it and then run `autoreconf -vi'?

(file #16321)

Yavor Doganov <yavor>
Wed 20 Aug 2008 08:53:59 AM UTC, comment #10: 

The macro definition is in config/procfs.m4.  I don't know where it came from, but definitely not Autoconf.

The test being performed there is going to fail in chroots that do not mount /proc.

FWIW, it doesn't fail on Debian autobuilders; from a Debian buildd log for 1.16.3:

checking procfs.h usability... no
checking procfs.h presence... no
checking for procfs.h... no
checking kernel support for /proc filesystem... yes
checking support for /proc psinfo struct... no
checking link to exe of process in /proc... /proc/self/exe
checking /proc/10669/cmdline terminated by nul... yes

Yavor Doganov <yavor>
Wed 20 Aug 2008 08:42:54 AM UTC, comment #9: 


> AC_SYS_PROCFS is not a standard autoconf macro


Thanks ... I guess it must be defined somewhere in GNUstep then ... so if the macro is generating a poor test, we need to change it once we know of a better test.

Richard Frith-Macdonald <CaS>
Group Member
Wed 20 Aug 2008 08:32:16 AM UTC, comment #8: 

AC_SYS_PROCFS is not a standard autoconf macro, just a macro polluting autoconf's namespace (a common practice, unfortunately).

Yavor Doganov <yavor>
Wed 20 Aug 2008 07:57:12 AM UTC, comment #7: 

Now you know which test in configure/configure.ac failed ... so you can look at the actual test in configure.ac and figure out why it gave a different result in your chrooted environment to your live environment.

Obviously something in the chrooted environment is different ... looking at configure and configure.ac I see that, 'checking kernel support for /proc filesystem' clearly comes from AC_SYS_PROCFS, a standard autoconf macro.
Looking at the expansion of the macro in configure, it seems it is using the 'mount' command, so presumably there is a problem with the mount command in your chrooted environment and you need to get that fixed.

Actually, there are four possibilities for where this should be fixed:

1. you consider the problem to be an error in the chrooted environment
1a. due to some error in your system setup if you changed things in your distrib ... this seems unlikely, but if it's the case then it's your own responsibility to fix it.
1b. due to an error in your distrib ... you should get the maintainers of the distrib to fix it.

2. a fault in the test (AC_SYS_PROCFS macro)
2a. should be reported to the maintainers of the autoconf package so that they can fix it
2b. you could contribute an additional test to GNUstep, so that we could use it after the AC_SYS_PROCFS macro, rather than waiting for a fix to be applied to autoconf

NB. If 2a has already been done, it might be that GNUstep could move to using a more recent version of autoconf, but having 2b woiuld still be worthwhile.


Richard Frith-Macdonald <CaS>
Group Member
Fri 18 Jul 2008 10:54:08 AM UTC, comment #6: 

OK, there must be something regarding /proc filesystem:

diff -u chrooted.config.log normal.config.log
@@ -5763,12 +5766,12 @@
 configure:15714: checking for procfs.h
 configure:15721: result: no
 configure:15742: checking kernel support for /proc filesystem
-configure:15770: result: no
+configure:15770: result: yes
 configure:15794: checking support for /proc psinfo struct

So, what should we do?

Funda Wang <fundawang>
Fri 18 Jul 2008 10:33:00 AM UTC, comment #5: 

To comment #4:
It is a real environment, and it seems has a normal /proc.

Funda Wang <fundawang>
Fri 18 Jul 2008 10:02:55 AM UTC, comment #4: 

IIRC normally on Linux NSProcessInfo is using /proc
to get information on the process.

If you're running on a chroot environment, you probably
don't have /proc, which explains why it would then fall back
to the `gnustep_base_user_main' hack.

Hope that helps in figuring out a solution

Thanks

Nicola Pero <nico>
Group Member
Fri 18 Jul 2008 05:31:19 AM UTC, comment #3: 

If it builds correctly normally, but does not build in the chrooted environment, then obviously the chrooted environment differs from the normal environment ... so you need to find out what is wrong with the chrooted environment.  The best way to do that is to look at the configure and build logs.  You can compare logs of the build inside and outside the chrooted environment to see what the difference is.  Then you can decide whether the issue is something that can be dealt with in the gnustep configure scripts or is something that has to be corrected in the environment.

Richard Frith-Macdonald <CaS>
Group Member
Fri 18 Jul 2008 05:23:10 AM UTC, comment #2: 

The problem is that it builds correctly in a non-chrooted environment.

Funda Wang <fundawang>
Fri 18 Jul 2008 05:02:39 AM UTC, comment #1: 

There's not much to do on here ... you would need to at least look at the configuration log and full build output to see what's going on (building the 'startup' package might help here as that automatically collects the relevant logs).

However, the error message does give some clue:

Linking library libgnustep-base ...
obj/NSProcessInfo.o: In function `main':
/home/fwang/rpm/BUILD/gnustep-base-1.16.3/Source/NSProcessInfo.m:913: undefined reference to `gnustep_base_user_main'

Now, this is linking the library itsself, and the gnustep_base_user_main function is supposed to be undefined at this point (since that function should be provided in programs using the library.  This suggests that there is a problem with the linker (or the arguments supplied to it).

However, on most systems I would not expect gnustep_base_user_main to be used at all, so something may be broken at the configuration stage.


Richard Frith-Macdonald <CaS>
Group Member
Fri 18 Jul 2008 02:23:54 AM UTC, original submission:  

I'm currently building gnustep-base 0.16.2 in a chrooted environment (Mandirva iurt). But it fails at:

GSFFCallInvocation.m:1080: warning: value computed is not used
GSFFCallInvocation.m:1080: warning: value computed is not used
GSFFCallInvocation.m:1081: warning: value computed is not used
GSFFCallInvocation.m:1081: warning: value computed is not used
GSFFCallInvocation.m:1081: warning: value computed is not used
GSFFCallInvocation.m:1081: warning: value computed is not used
GSFFCallInvocation.m:1082: warning: value computed is not used
GSFFCallInvocation.m:1082: warning: value computed is not used
GSFFCallInvocation.m:1082: warning: value computed is not used
GSFFCallInvocation.m:1082: warning: value computed is not used
GSFFCallInvocation.m:1085: warning: value computed is not used
GSFFCallInvocation.m:1097: warning: value computed is not used
GSFFCallInvocation.m:1097: warning: value computed is not used
GSFFCallInvocation.m:1101: warning: value computed is not used
GSFFCallInvocation.m: At top level:
GSFFCallInvocation.m:186: warning: 'gs_subtype' defined but not used
 Linking library libgnustep-base ...
obj/NSProcessInfo.o: In function `main':
/home/fwang/rpm/BUILD/gnustep-base-1.16.3/Source/NSProcessInfo.m:913: undefined reference to `gnustep_base_user_main'
collect2: ld returned 1 exit status

Funda Wang <fundawang>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #16321:  procfs.diff added by yavor (675B - text/x-patch - Patch supposed to fix the problem)
file #16133:  build.0.20080718021337.log added by fundawang (46KiB - application/octet-stream - The buildlog and the build dependencies)
file #16134:  rpm_qa.0.20080718021337.log added by fundawang (7KiB - application/octet-stream - The buildlog and the build dependencies)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by yavor (Posted a comment)
  • -email is unavailable- added by nico (Posted a comment)
  • -email is unavailable- added by CaS (Posted a comment)
  • -email is unavailable- added by fundawang (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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-08-20 CaS StatusNone Fixed
        Open/ClosedOpen Closed
    2008-08-20 yavor Attached File- Added procfs.diff, #16321
    2008-07-18 fundawang Attached File- Added build.0.20080718021337.log, #16133
        Attached File- Added rpm_qa.0.20080718021337.log, #16134

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code