Summary: | net-libs/xulrunner-1.9.1.2-r1 + dev-libs/openssl fails to build when PROGRAM is set in the calling shell | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Mark A Rada <marada> |
Component: | Current packages | Assignee: | Mozilla Gentoo Team <mozilla> |
Status: | RESOLVED FIXED | ||
Severity: | trivial | CC: | base-system |
Priority: | Lowest | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
The build.log
The environment log from the XULrunner build |
Description
Mark A Rada
2009-08-12 03:04:34 UTC
Created attachment 200984 [details]
The build.log
This looks more like a bug in your toolchain rather then xulrunner. Please rebuild gcc and run fix_libtool_files.sh (In reply to comment #2) > This looks more like a bug in your toolchain rather then xulrunner. Please > rebuild gcc and run fix_libtool_files.sh > Ok, I gave it a try and it did not work. I tried a revdep-rebuild and apparently NSS needs to be fixed, but it also will not compile. I tried to emerge -e system, but it failed at openssl. I, too, now suspect something else is wrong. Please advise further. (In reply to comment #3) > (In reply to comment #2) > > This looks more like a bug in your toolchain rather then xulrunner. Please > > rebuild gcc and run fix_libtool_files.sh > > > > Ok, I gave it a try and it did not work. I tried a revdep-rebuild and > apparently NSS needs to be fixed, but it also will not compile. I tried to > emerge -e system, but it failed at openssl. I, too, now suspect something else > is wrong. > > Please advise further. > Post you rbuild error for openssl if you would please. (In reply to comment #4) > Post you rbuild error for openssl if you would please. > ack -march=k8-sse3 -O2 -pipe -c -o prime.o prime.c x86_64-pc-linux-gnu-gcc -DMONOLITH -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -Wall -DMD32_REG_T=int -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -march=k8-sse3 -O2 -pipe -Wa,--noexecstack -march=k8-sse3 -O2 -pipe -c -o cms.o cms.c make[1]: Circular ferrous <- ferrous dependency dropped. make[1]: *** No rule to make target `shell.o', needed by `ferrous'. Stop. make[1]: Leaving directory `/var/tmp/portage/dev-libs/openssl-0.9.8k-r1/work/openssl-0.9.8k/apps' make: *** [build_apps] Error 1 * * ERROR: dev-libs/openssl-0.9.8k-r1 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 2624: Called die * The specific snippet of code: * emake -j1 all rehash || die "make all failed" * The die message: * make all failed * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/dev-libs/openssl-0.9.8k-r1/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-libs/openssl-0.9.8k-r1/temp/environment'. * I can get the same error when I try to build a stock openssl (same version, no patches applied), but the problem actually seems to show up first when I try to `make depend': making depend in apps... make[1]: Entering directory `/root/openssl-0.9.8k/apps' gcc: ferrous: No such file or directory gcc: shell.c: No such file or directory make[1]: Leaving directory `/root/openssl-0.9.8k/apps' There is no shell.c file in the entire openssl archive for versions 0.9.8k, I've also checked 0.9.8j, it isn't there either...so the plot thickens...halp! :( Wranglers please deside who should take this bug. It is a toolchain issue, has nothing to do with mozilla. This looks like something is polluting the builds. Could you post : /var/tmp/portage/net-libs/xulrunner-1.9.1.2-r1/temp/environment Created attachment 203945 [details]
The environment log from the XULrunner build
I can reproduce: (export PROGRAM="ferrous shell"; ebuild /usr/portage/net-libs/xulrunner/xulrunner-1.9.1.3.ebuild clean install ) Results in the same error. Xulrunner and openssl should probably filter PROGRAM out because it leaks into their build scripts, but nevertherless you should find out where PROGRAM="ferrous shell" is set and if possible try to unset it. (In reply to comment #9) > I can reproduce: > (export PROGRAM="ferrous shell"; ebuild > /usr/portage/net-libs/xulrunner/xulrunner-1.9.1.3.ebuild clean install ) > Results in the same error. Xulrunner and openssl should probably filter PROGRAM > out because it leaks into their build scripts, but nevertherless you should > find out where PROGRAM="ferrous shell" is set and if possible try to unset it. > I know where that came from, I'm the cause of my own troubles! I set that variable as part of my .zshrc. I tried removing it and this fixes the problem xulrunner. Thank you. Mark as you have resolved your problems I am gonna closed invalid, if for any reason you feel the need to reopen this please feel free to. (In reply to comment #11) > Mark as you have resolved your problems I am gonna closed invalid, if for any > reason you feel the need to reopen this please feel free to. > Quoting comment #9: >Xulrunner and openssl should probably filter PROGRAM out because it leaks into >their build scripts. Is this not something that needs to be fixed? Someone else will probably make this mistake themselves in the future. (In reply to comment #12) > (In reply to comment #11) > > Mark as you have resolved your problems I am gonna closed invalid, if for any > > reason you feel the need to reopen this please feel free to. > > > > Quoting comment #9: > >Xulrunner and openssl should probably filter PROGRAM out because it leaks into >their build scripts. > > Is this not something that needs to be fixed? Someone else will probably make > this mistake themselves in the future. > The problem with filtering in anything mozilla based is that certain options can be passed via PROGRAM that will not break the build system, it will actually enhance the build. There are not well documented and not well known. This is one reason we do not check for/unset in the ebuild. (In reply to comment #13) > > The problem with filtering in anything mozilla based is that certain options > can be passed via PROGRAM that will not break the build system, it will > actually enhance the build. There are not well documented and not well known. > This is one reason we do not check for/unset in the ebuild. > Hmm, ok, but I think this can be resolved in a way that is both safe and usable. Perhaps a message noting that extra environment variables (e.g. PROGRAM) can break the ebuild? Perhaps a USE flag that turns on/off filtering of extra variables like PROGRAM? This also applies to openssl, do you know if PROGRAM can be useful for that or if that ebuild can safely filter out PROGRAM? (In reply to comment #14) > (In reply to comment #13) > > > > The problem with filtering in anything mozilla based is that certain options > > can be passed via PROGRAM that will not break the build system, it will > > actually enhance the build. There are not well documented and not well known. > > This is one reason we do not check for/unset in the ebuild. > > > > Hmm, ok, but I think this can be resolved in a way that is both safe and > usable. > > Perhaps a message noting that extra environment variables (e.g. PROGRAM) can > break the ebuild? Perhaps a USE flag that turns on/off filtering of extra > variables like PROGRAM? > > This also applies to openssl, do you know if PROGRAM can be useful for that or > if that ebuild can safely filter out PROGRAM? > I see with a simple grep that it uses apps/Makefile:PROGRAM= openssl whatelse it will allow to be passed via PROGRAM I could not answer. I do not manager and never really review the source. I noticed a warning the other day post-install letting me know about this issue, which is enough to give me a hint at what I'm doing wrong, but further improvement in the future would be nice. I consider this bug closed now. |