Date: Sat, 26 Dec 2015 12:05:20 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Colin Percival <cperciva@freebsd.org> Cc: Daniel Eischen <deischen@freebsd.org>, 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: <20151226100520.GG3625@kib.kiev.ua> 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, Dec 25, 2015 at 04:38:24PM -0800, 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...
I fixed all issues I was aware of with dlopen("libthr"), see the longer
explanation at
https://lists.freebsd.org/pipermail/freebsd-threads/2014-December/005636.html
If any of the issue which prevents dlopening libthr left, please provide
me with the test case.
Note that issues which might break runtime due to libc appears in the
DT_NEEDED flatten order before libthr should be equially valid for the
dlopen().
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151226100520.GG3625>