Summary: | Apache 2.0.49-r3 ebuild fails | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jim Sager <jim.sager> |
Component: | New packages | Assignee: | Chuck Short (RETIRED) <zul> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | dev-portage, swegener |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
config.layout
config.log |
Description
Jim Sager
2004-06-02 07:00:27 UTC
Created attachment 32524 [details]
config.layout
Created attachment 32525 [details]
config.log
don't know if this is related to bug 49363 which version of binutils are you using? binutils-2.14.90.0.8-r1 Sorry, I was wrong. I had a closer look at config.log. configure:2992: checking for C compiler default output file name configure:2995: gcc -O2 -march=pentium4 -fomit-frame-pointer -pipe -I/usr/local/include -s -ldb4 conftest.c >&5 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/../../../../i686-pc-linux-gnu/bin/ld: cannot find -ldb4 collect2: ld returned 1 exit status This bug seems to appear when LDFLAGS is in the current environment and is exported. The ebuild adds -ldb4 to LDFLAGS, but if LDFLAGS wasn't declared yet it will become by default a private variable and will not be used by configure. If you have LDFLAGS in your environment, the variable will be used by configure and fail. But the real error is that -ldb4 isn't valid, correct would be -ldb-4 but that fails also, because sys-libs/db doesn't symlinks libdb-4 to libdb-4.* I'll add dev-portage@g.o to CC because I think that this issue migh affect portage. In ebuild.sh in dyn_compile(): [ "${LDFLAGS-unset}" != "unset" ] && export LDFLAGS portage will export LDFLAGS only if it is set. I think this should be modified to export LDFLAGS="" if LDFLAGS has not been set yet. Same applies to all other FLAG's. I had LDFLAGS="-s" in make.conf. I had this set to install one of the other packages in Gentoo. I commented out the line and was able to install Apache without any problems. Closing bug Chuck, I don't consider this bug fixed. Parts of flag-o-matic eclass and I suppose maybe several other ebuilds besides apache rely on the fact that the *FLAGS vars have been exported to the build environment. This is not always the case. I think that portage should set the *FLAGS vars to sane defaults and export them, if they're not defined in make.{conf,globals} or passed via the use environment. Currently they're only exported if they have been set. And the fact that -ldb4 is invalid still needs to be addressed. This WORKSFORME is just because LDFLAGS will never be passed to configure, because it is never exported to the environment! |