Date: Thu, 08 Feb 2001 11:44:06 +0200 From: Maxim Sobolev <sobomax@FreeBSD.org> To: ports@FreeBSD.org Subject: Re: Strange problems with dynamic linking of libGL.so.1 from XFree86-4.0.2_5 Message-ID: <3A826A65.3436847B@FreeBSD.org> References: <3A6C3D19.E1F56291@FreeBSD.org> <3A755D84.266A80E7@FreeBSD.org> <86vgqn7vj4.wl@cheerful.com> <3A8188ED.FC2A6241@FreeBSD.org> <200102080052.f180qxH02749@vashon.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
John Polstra wrote:
> In article <3A8188ED.FC2A6241@FreeBSD.org>,
> Maxim Sobolev <sobomax@FreeBSD.ORG> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A826A65.3436847B>