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

 
 

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

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

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

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

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

Richard Frith-Macdonald <CaS>
Project 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>
Project 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>
Project 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>
Project 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>
Project 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>
Project 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>

 

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

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 20 Aug 2008 11:26:32 AM UTCCaSStatusNone=>Fixed
      Open/ClosedOpen=>Closed
    Wed 20 Aug 2008 09:30:07 AM UTCyavorAttached File-=>Added procfs.diff, #16321
    Fri 18 Jul 2008 02:23:54 AM UTCfundawangAttached File-=>Added build.0.20080718021337.log, #16133
      Attached File-=>Added rpm_qa.0.20080718021337.log, #16134

    Back to the top


    Powered by Savane 3.1-cleanup1