This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]


On Fri, Apr 20, 2012 at 6:08 PM, Joern Rennecke <> wrote:
>>> Even better, you could use symbolic tags, and have the linker script
>>> assign precedence values to these tags.
>> It won't help us.
> Maybe it wouldn't buy you more than the secondary symbols right now, but
> it would give a lot of flexibility to rearrange and combine different
> peoples ideas of link priority.
> Another thought on symbols priorities: with pthread, using symbols of
> different priorities is really a crutch - and it doesn't really work
> that well for static linking. ?What is really wanted is that
> whenever one of a set of object files is linked in, a whole set of symbols
> should be satisfied from a different place. ?Maybe if, for a static pthread,
> we'd put the pthread-aware I/O etc. into a special .text.pthread section
> or somesuch, which would normally discarded, but had a mechanism to use them
> if a special symbol is set (or used?) from an object file that provides
> a pthread API function.

We want to provide a .o file which can take advantage of all versions of
Linux we support.  For a function, foo, in glibc, we can use it only if it is
available on all versions of glibc or we provide our own implementation of
foo inside the .o file.  With our own foo, the one in glibc will never be used.
When our own foo is marked as secondary, the one in glibc will be
used if it exists.  However we do want to use foo in glibc if it exists.

Putting our own foo in a section with a special prefix in section name,
like .secondary_*, works with linker support.  But it isn't very reliable.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]