From owner-freebsd-ports Thu Feb 8 1:44:56 2001 Delivered-To: freebsd-ports@freebsd.org Received: from blizzard.sabbo.net (smtp.sabbo.net [193.193.218.18]) by hub.freebsd.org (Postfix) with ESMTP id 86A6437B684 for ; Thu, 8 Feb 2001 01:44:30 -0800 (PST) Received: from vic.sabbo.net (root@vic.sabbo.net [193.193.218.112]) by blizzard.sabbo.net (8.10.1/8.10.1) with ESMTP id f189i6g17137 for ; Thu, 8 Feb 2001 11:44:10 +0200 Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vic.sabbo.net (8.11.2/8.11.2) with ESMTP id f189i6m09923 for ; Thu, 8 Feb 2001 11:44:06 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Message-ID: <3A826A65.3436847B@FreeBSD.org> Date: Thu, 08 Feb 2001 11:44:06 +0200 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: uk,ru,en MIME-Version: 1.0 To: ports@FreeBSD.org Subject: Re: Strange problems with dynamic linking of libGL.so.1 from XFree86-4.0.2_5 References: <3A6C3D19.E1F56291@FreeBSD.org> <3A755D84.266A80E7@FreeBSD.org> <86vgqn7vj4.wl@cheerful.com> <3A8188ED.FC2A6241@FreeBSD.org> <200102080052.f180qxH02749@vashon.polstra.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org John Polstra wrote: > In article <3A8188ED.FC2A6241@FreeBSD.org>, > Maxim Sobolev wrote: > > FUJISHIMA Satsuki wrote: > > > > > As libc_r does not have libc feature now, there's no reason to avoid > > > linking -lc_r against shared libraries, I think. > > > > > > Index: contrib/gcc.295/config/freebsd.h > > > =================================================================== > > > RCS file: /home/ncvs/src/contrib/gcc.295/config/freebsd.h,v > > > retrieving revision 1.31 > > > diff -u -r1.31 freebsd.h > > > --- contrib/gcc.295/config/freebsd.h 2001/01/25 18:57:13 1.31 > > > +++ contrib/gcc.295/config/freebsd.h 2001/02/06 08:54:23 > > > @@ -76,10 +76,8 @@ > > > (like the default, except no -lg, and no -p). */ > > > #undef LIB_SPEC > > > #define LIB_SPEC "\ > > > - %{!shared: \ > > > - %{!pg: %{pthread:-lc_r} -lc} \ > > > - %{pg: %{pthread:-lc_r_p} -lc_p} \ > > > - }" > > > + %{!pg: %{pthread:-lc_r} %{!shared:-lc}} \ > > > + %{pg: %{pthread:-lc_r_p} %{!shared:-lc_p}}" > > > > > > > > > /************************[ Target stuff ]***********************************/ > > > > David, John what do you think about this patch? > > I think it would be a mistake to implement this. > > If the patch above were used then the shared library would contain > a dependency on a specific version of libc_r -- say libc_r.so.4. > But that version of libc_r is intimately tied to a specific version > of libc. Now if the application were run on a later version of > FreeBSD, it might get a newer libc which would be incompatible with > libc_r.so.4. Why not link against both libc_r and libc? Then the library would contain dependency to the particular libc_r/libc pair and all should be OK. #define LIB_SPEC "\ - %{!shared: \ - %{!pg: %{pthread:-lc_r} -lc} \ - %{pg: %{pthread:-lc_r_p} -lc_p} \ - }" + %{!pg: %{pthread:-lc_r} -lc} \ + %{pg: %{pthread:-lc_r_p} -lc_p}" > I think we need to view both libc and libc_r as basic low-level > system libraries which are to be linked once and only once into > the application. Other shared libraries should not have explicit > dependencies on them. If an application uses a library that requires > threads then the application itself should be linked with -lc_r or > -pthread. But that makes dlopen()ing a shared module linked against libc_r by the program that not linked against libc_r impossible. Also this makes life harder when linking against such libraries, for example if the shared library (GL in my example) requires libc_r then all programs that want to link against it should explicitly use -pthread or -lc_r. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message