Opened 7 years ago

#2061 new defect

Processing of $LDFLAGS should occur before first compiler test

Reported by: mplayer.8eaf7cd8e5128d8191fe@… Owned by: diego@…
Priority: normal Component: build system
Version: 1.0rc4 Severity: minor
Keywords: Cc:
Blocked By: Blocking:
Reproduced by developer: Analyzed by developer:

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.

Attachments (1)

0001-early-ldflags.patch (1.0 KB) - added by mplayer.8eaf7cd8e5128d8191fe@… 7 years ago.
Move LDFLAGS handling above the test for a working compiler.

Download all attachments as: .zip

Change History (1)

Changed 7 years ago by mplayer.8eaf7cd8e5128d8191fe@…

Move LDFLAGS handling above the test for a working compiler.

Note: See TracTickets for help on using tickets.