svn commit: r292723 - in head: lib/libc share/mk

[Daniel Eischen]

On Fri, 25 Dec 2015, Colin Percival wrote:

> On 12/25/15 13:03, Daniel Eischen wrote:
>> On Fri, 25 Dec 2015, Ed Schouten wrote:
>>> 2015-12-25 12:29 GMT+01:00 Colin Percival <cperciva at freebsd.org>:
>>>>   Make libxnet.so a symlink to libc.so.  This makes `-lxnet` a no-op, as
>>>>   POSIX requires for the c99 compiler.
>>>
>>> I seem to remember I had some issues in the past where I was linking
>>> against libc explicitly. Maybe it had something to do with linking
>>> both against -lpthread and -lc, but if you pass in -lc later on the
>>> command line, libc overrides the symbols that have to be provided by
>>> -lpthread?
>
> I just did some tests with one of my pthread-using tools, and it passes
> all of my tests with -lc added before or after -lpthread.  Can you
> remember any details of how the problems showed up?  Is it possible that
> this has been fixed since then?  I know there's a lot of tricks to make
> sure that the right versions of functions get called.
>
>>> If that's (still) the case, would it make sense to just provide
>>> libxnet in the form of an empty .a file instead?
>>
>> I think that's a good point.  Using -lanything shouldn't introduce an
>> unexpected link order.
>
> Yes, adding a dummy library was my first thought, but kib pointed out
> that a symlink was much simpler.  Obviously it never occurred to me that
> linking to a library which we were going to be linking to anyway would
> cause problems...

It is hard to contemplate a way this could cause problems (after
reading Konstantin's response with regard to threads).  The only
thought I have is if the application is trying to override libc
symbols (which are weak) with other weak symbols.  The first
weak wins.

-- 
DE