Hi, this bug deals with portage's and flag-o-matic's handling of *FLAGS. Currently parts of flag-o-matic rely on the fact that the *FLAGS variables have been exported to the environment, so that they can be used by configure without the need to pass them via command-line arguments. The variables are not always exported, as ebuild.sh only exports them if they have been set previously. code of ebuild.sh in dyn_compile() [ "${LDFLAGS-unset}" != "unset" ] && export LDFLAGS code of flag-o-matic.eclass append-ldflags() { LDFLAGS="${LDFLAGS} $*" return 0 } LDFLAGS is not normally set, so it will not be export to the environment by ebuild.sh. This will lead to the fact that LDFLAGS will become a normal shell variable once append-ldflags is used in an ebuild. And so it will never make it's way to configure. See bug 52775 where this lead to a failure. Sure, the real error is that -ldb4 is invalid and the developer should've noticed that. Anyway, if LDFLAGS had been exported to the environment, he would have noted it. Currently I see two solutions for this. First, to make flag-o-matic export the variables whenever it touches them. The largest part already does it. And the other solution is to make ebuild.sh always export the *FLAGS wether they have been set or not. Best would be to initilaizie them to "". But in my oppinion both things need to done, patch flag-o-matic and ebuild.sh. I'm going to attach two patches for this. Sven
Created attachment 34092 [details, diff] ebuild.sh.patch
Created attachment 34093 [details, diff] flag-o-matic.eclass.patch
ive fixed the flag-o-matic stuff ... i'll let portage team figure out the ebuild.sh stuff
I do not believe this is the correct way to handle this for portage. Makefiles may react differently when these flags are set and thus portage should not export them as empty variables.
many configure scripts would react that way i think
With flag-o-matic exporting the vars, this should be fixed and bug can be closed?
Closing, see comments #4 and #5
