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 <cperc...@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
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
