| All Forums |
Register |
Login |
Search |
Subscriptions |
My Profile |
Inbox |
| Tool Warehouse |
FAQs |
Resources |
Help |
Member List |
Address Book |
Logout |
|
|
cc w/ LDFLAGS -l and ./configure croaks
|
Logged in as: Guest |
| Users viewing this topic: none |
|
Login  |
|
|
 cc w/ LDFLAGS -l and ./configure croaks - Dec. 30, '05, 10:36:26 AM
|
|
|
breiter
Posts: 338
Joined: Jun. 14, '04,
From: Washington, DC
Status: offline
|
I have encountered a problem with /bin/cc freaking out when used with ./configure scripts if LDFLAGS has a -l option (eg. LDFLAGS = "-L/usr/local/lib -L/usr/local/ssl/lib -lbind").
Basically, if -l is in the LDFLAGS list then line 510 of cc gets hit and it generates an error:
-l must be used as an operand, not an option
For example, in the clamav build, it croaks out detecting the C compiler and later when trying to establish that it can link to zlib and gmp.
Commenting out line 511 and 512 that generate the warning seems to correct the problem.
|
|
|
|
|
RE: cc w/ LDFLAGS -l and ./configure croaks - Dec. 31, '05, 9:30:26 AM
|
|
|
markfunk
Posts: 629
Joined: Mar. 31, '03,
Status: offline
|
My first thought would be that putting a "-l option" in LDFLAGS is wrong.
And the error you get from /bin/cc is correct.
The "-l option" is position sensitive and should be an operand placed in the correct
order. LDFLAGS should only contain flags that are not position sensitive.
|
|
|
|
|
RE: cc w/ LDFLAGS -l and ./configure croaks - Dec. 31, '05, 10:09:26 AM
|
|
|
breiter
Posts: 338
Joined: Jun. 14, '04,
From: Washington, DC
Status: offline
|
I'm pretty sure that -lbind it was put there by Rodney's BIND 9 package. It may be wrong, but it is there.
This is in profile.lcl:
# pkg_add :: LDFLAGS bind extend for installed software
export LDFLAGS="${LDFLAGS} -lbind"
This is in chs.lcl:
# pkg_add :: LDFLAGS bind extend for installed software
if ( $?LDFLAGS ) then
setenv LDFLAGS "${LDFLAGS} -lbind"
else
setenv LDFLAGS "lbind"
endif
Also the ./configure script that I'm working with pretty much does the same thing down the road when creating a test binary with zlib. So for me, the restrictive behavior or cc is counter-productive since gcc is happy with the -l arguments and people are actively using that behavior in the real world.
< Message edited by breiter -- Dec. 31, '05, 10:11:17 AM >
|
|
|
|
|
RE: cc w/ LDFLAGS -l and ./configure croaks - Dec. 31, '05, 3:51:00 PM
|
|
|
markfunk
Posts: 629
Joined: Mar. 31, '03,
Status: offline
|
Using the "-l option" as an option is dangerous.
Not all linkers will re-search a library specified on the command line
to find unresolved symbols.
Normally, ld searches the library once - when it encounters the library name
in the order specified on the command line.
So if you put "-lbind" before your object files, there is no
guarantee bind.a will be used to resolve symbols in the object files.
The -l option is normally specified _after_ all object files (or their corresponding C files).
The error in /bin/cc is to ensure you have -l as an operand
and helps you avoid making a mistake.
Whether or not gnu ld still behaves this way, I don't know.
As for Microsoft link.exe, it is more flexible and forgiving
so putting -l before object files may just work. But this isn't
portable.
And for /bin/cc, it is just following the UNIX stds of c89 and c99,
and historical UNIX practice.
One of the reasons we liked the idea of /bin/cc being written as a shell script
is that customers could modify it to their specific needs.
If you want to allow this behaviour, feel free to make the mods.
|
|
|
|
 New Messages |
 No New Messages |
 Hot Topic w/ New Messages |
 Hot Topic w/o New Messages |
|
 Locked w/ New Messages |
 Locked w/o New Messages |
|
 Post New Thread
Reply to Message
Post New Poll
Submit Vote
Delete My Own Post
Delete My Own Thread
Rate Posts |
|
|
|
Printable Version
