| Summary: | dev-util/boost-build-1.34.1 fails to compile with new LIBS pre-flag | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Mark Fisher <mark.j.fisher> |
| Component: | New packages | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
full error message from ebuild
a patch to stop emerge failing |
||
*** This bug has been marked as a duplicate of bug 210029 *** Created attachment 143447 [details]
full error message from ebuild
Created attachment 143448 [details, diff]
a patch to stop emerge failing
|
emerging with 1.34.1 gives: ... ./bootstrap/jam0 -f build.jam --toolset=cc --toolset-root= --with-python ...found 45 targets... ...updating 2 targets... [MKDIR] bin.linux [COMPILE] bin.linux/bjam x86_64-pc-linux-gnu-gcc: : No such file or directory i debugged the ebuild, and on my system the LDFLAGS is empty, and removing LIBS= part fixes the issue, so I created a small patch: --- boost-build-1.34.1-r1.ebuild 2008-02-13 20:47:45.000000000 +0000 +++ /usr/portage/dev-util/boost-build/boost-build-1.34.1.ebuild 2008-02-13 14:06:01.000000000 +0000 @@ -60,11 +60,7 @@ # and link targets to make it use the LDFLAGS var, or # b) a simple dirty workaround by injecting the LDFLAGS in the LIBS env var # (which should not be set by us). - if [[ "${LDFLAGS}" != "" ]] ; then - LIBS="${LDFLAGS}" CC=$(tc-getCC) ./build.sh ${toolset} $(use_with python) || die "building bjam failed" - else - CC=$(tc-getCC) ./build.sh ${toolset} $(use_with python) || die "building bjam failed" - fi + LIBS="${LDFLAGS}" CC=$(tc-getCC) ./build.sh ${toolset} $(use_with python) || die "building bjam failed" } src_install() {