Date: Sat, 26 Dec 2015 12:26:27 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: Colin Percival <cperciva@freebsd.org> Cc: Ed Schouten <ed@nuxi.nl>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r292723 - in head: lib/libc share/mk Message-ID: <Pine.GSO.4.64.1512261220260.19056@sea.ntplx.net> In-Reply-To: <567DE180.3040601@freebsd.org> References: <201512251129.tBPBTIZp058825@repo.freebsd.org> <CABh_MKmMT6EuKMPOan=ibL_J3zbSPSVFk5eAbuEoNr_hjBNq8Q@mail.gmail.com> <Pine.GSO.4.64.1512251601360.15474@sea.ntplx.net> <567DE180.3040601@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.1512261220260.19056>