[cfe-dev] [libcxx-dev] Is the C++ filesystem object file installed via LLVM's APT repository missing symbols?

[Brian Cain via cfe-dev]

This is the intended design of GNU ld.  Some linkers follow this behavior,
some don't.  e.g. IIRC lld chose to have an implicit grouping (like ld's
start-group/end-group), which comes w/pros and cons.  Pros: like you said,
you needn't concern yourself with the order of the libs.  If you are
consuming several different libraries, one could see the perspective that
from up here at the executable's perspective, you don't care how the linker
does symbol resolution and one could imagine that it might not even matter
that it takes more time for it to go and search the ones that appear earlier
on the command line.  Cons: increased link time, cyclical dependencies among
libraries are easy to introduce now because the linker won't alert you to
the problem.

 

Relevant details from the ld.bfd manpage:

 

--start-group archives --end-group

 

.

The specified archives are searched repeatedly until no new undefined
references are created. Normally, an archive is searched only once in the
order that it is specified on the command line. If a symbol in that archive
is needed to resolve an undefined symbol referred to by an object in an
archive that appears later on the command line, the linker would not be able
to resolve that reference. By grouping the archives, they all be searched
repeatedly until all possible references are resolved.

Using this option has a significant performance cost. It is best to use it
only when there are unavoidable circular references between two or more
archives.

 

From: libcxx-dev <libcxx-dev-bounces at lists.llvm.org> On Behalf Of Louis
Dionne via libcxx-dev



To clarify, what I meant is that from a very naive point of view, the order
in which you provide `-l`'s on the command line shouldn't matter -- it
should work as long as you provide the right set of `-l`'s. I'm puzzled
every time a tool (e.g. `ld`) behaves differently based on the order of
command line arguments.

 

Maybe there's a good reason for this, though. Maybe the cfe-dev folks can
explain?

 

Louis

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190402/38199d5a/attachment.html>