| Summary: | app-text/recode-3.6-r2 does not respect LDFLAGS | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Diego Elio Pettenò (RETIRED) <flameeyes> |
| Component: | New packages | Assignee: | Gentoo Shell Tools project <shell-tools> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 331933 | ||
|
Description
Diego Elio Pettenò (RETIRED)
2008-02-11 20:39:53 UTC
Diego, could you provide some additional information here? What LDFLAGS do you pass and how do you check? AFAIS recode links this library wit LDFLAGS here... I cannot speak to what flags Diego used, but I can confirm that app-text/recode-3.6-r2 does not honor LDFLAGS for that file. I tested by including -Wl,-z,now in my LDFLAGS, but the library still has LAZY loading, rather than NOW loading, according to scanelf. After spending quite a bit of time poking at it, this appears to be some sort of autotools bug in that version. The generated Makefile does the right thing, but the resulting library is wrong. I can run libtool by hand with the same LDFLAGS values, and observe the same incorrect output. I moved forward to app-text/recode-3.6_p15, which already updates the autotools for other reasons. As a side effect of that update, the problematic libtool is replaced with one that preserves LDFLAGS correctly. In app-text/recode-3.6_p15, librecode.so has NOW loading, which is what my LDFLAGS should cause. A comparison of the two libtool invocations by the different versions shows no meaningful differences. Moving forward to the new version seems like the simplest course of action. removed. thx for the analysis |
