Opened 12 years ago
#2061 new defect
Processing of $LDFLAGS should occur before first compiler test
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | normal | Component: | build system |
| Version: | 1.0rc4 | Severity: | minor |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Reproduced by developer: | no | Analyzed by developer: | no |
Description
In 1.0_rc4 as of early April 2012, the mplayer configure script tests for a "working compiler" before it adds the environment's $LDFLAGS into $extra_ldflags. This causes two problems: first, it needlessly fails the test in environments where passing $LDFLAGS is a prerequisite to success. Second, it may allow the "working compiler" check to succeed when the user has broken $LDFLAGS, which will not fail until later when configure appends $LDFLAGS to $extra_ldflags. I ran afoul of the first case. In my environment, no C program, even "Hello, world", can link without including the value of $LDFLAGS, since libc.so is not in the standard library search path. I do pass a valid -L/path/to/libc via $LDFLAGS, so any compilation that uses $LDFLAGS works. Moving the block that adjusts extra_ldflags up to before the check for a "working compiler" allowed mplayer to build for me.[1] I will attach the patch that I used.
[1] There is a separate LDFLAGS-related issue with programs built for the build host, which also caused a failure for me. However, in the interest of keeping things straight, I will address that in a separate bug report. The patch shown fixes the problem described above.
Move LDFLAGS handling above the test for a working compiler.