[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Library linking

From: David Boyce
Subject: Re: Library linking
Date: Mon, 3 Oct 2011 10:55:43 -0400

On Mon, Oct 3, 2011 at 4:21 AM, Brendan Heading
<address@hidden> wrote:
> I get the impression I'll have to have a look at the source to see
> what it is doing here, but it sounds a bit like Make expands the
> library to its full name but does not add the new name to the list of
> prerequisites - which is a bit odd.

This analysis seems right; it works fine for a library which already
exists (e.g. using -lc instead of -lhello). I also verified that
current CVS has the same behavior.

> It's also a little odd that -l<name> is expanded and then the expanded
> version is passed to the command line. That seems to assume that GCC
> is in use; other compilers might need the -l parameter (or a different
> parameter altogether).

I don't follow this reasoning, in fact I think the logic goes the
other way. All compilers through all time (with the usual
Redmond-based exception) have handled -lfoo the same way. Essentially
they do just what GNU make is doing, searching the path and replacing
-lfoo with the full path to the found library. The complication arises
in the preference order of shared vs static libraries;
compilers/linkers have not always agreed on how to handle this. By
making the substition, GNU make assures that the library on which it
based its decision is the one that gets used. The alternative would be
to let the compiler do another search by potentially different rules,
which could cause really subtle build bugs and also introduce a race
condition.Bottom line, if you don't like the way make searches for
libraries your only option is to not use this feature, and if you do
then make's substitution is the right thing to do.

-David Boyce

reply via email to

[Prev in Thread] Current Thread [Next in Thread]