Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 13 Jun 2013 20:41:51 +0200
From:      Baptiste Daroussin <bapt@FreeBSD.org>
To:        olli hauer <ohauer@gmx.de>
Cc:        ports@FreeBSD.org
Subject:   Re: [CFT] Fixing/changing LIB_DEPENDS
Message-ID:  <20130613184151.GD44980@ithaqua.etoilebsd.net>
In-Reply-To: <51BA093E.9090303@gmx.de>
References:  <20130613130730.GK99460@ithaqua.etoilebsd.net> <51B9FA28.3020303@gmx.de> <20130613175005.GC44980@ithaqua.etoilebsd.net> <51BA093E.9090303@gmx.de>

next in thread | previous in thread | raw e-mail | index | archive | help

--ZJcv+A0YCCLh2VIg
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 13, 2013 at 08:02:38PM +0200, olli hauer wrote:
> On 2013-06-13 19:50, Baptiste Daroussin wrote:
> > On Thu, Jun 13, 2013 at 06:58:16PM +0200, olli hauer wrote:
> >> On 2013-06-13 15:07, Baptiste Daroussin wrote:
> >>> Hi,
> >>>
> >>> Here is a patch to fix LIB_DEPENDS.
> >>>
> >>> First what is/are the problem of LIB_DEPENDS.
> >>>
> >>> LIB_DEPENDS relies on of ldconfig -r to get its valid or not installe=
d shared
> >>> libraries, problem is:
> >>> liba-5.2.so and liba-5.so.2 will both be a-5.2 for ldconfig -r, which=
 is not
> >>> really what we want.
> >>>
> >>> secondly ldconfig -r is only able to print something for libraries in=
 the form
> >>> of: lib<name>.so[.number], while we have no technical limitation to e=
nforce this
> >>> form and it is more and more common to find libraries in the followin=
g form:
> >>> lib<name>.so.major.minor.patch and to get them working properly right=
 know we
> >>> have to patch the upstream build system, to send some magic tricks on=
 libtool
> >>> etc, all that kind of things all of us loves to deal with.
> >>>
> >>> What I do propose is a new form of LIB_DEPENDS in addition to the cur=
rent one:
> >>> LIB_DEPENDS=3D	bla.so[numberwithlongorwhatever]:${PORTSDIR}/cat/bla
> >>>
> >>> What the framework will do, is lookup in all libraries directories for
> >>> libbla.so[numberwithdotsorwhatever] test if it exists (test -f also v=
alidate the
> >>> symlink is pointing to a regular file) if /usr/bin/file is present on=
 your
> >>> system it will validate the pointed file is really a shared library.
> >>>
> >>> Any review welcome: http://people.freebsd.org/~bapt/fix-libdepends.pa=
tch
> >>>
> >>> This idea behind this patch is on mid/long term to remove the other L=
IB_DEPENDS
> >>> forms.
> >>>
> >>> I do plan to commit this on next friday 2013-06-21.
> >>>
> >>> regards,
> >>> Bapt
> >>>
> >>
> >>
> >>
> >> Hm,
> >>
> >> so this is a modern extended incarnation of the old LIB_DEPENDS notati=
on
> >> For example pcre.3:... becomes pcre:...
> >>
> >> Isn't this something that can be handled with some additional code in =
pathfix?
> >>
> >> --
> >> regards,
> >> olli
> >>
> >=20
> > Either I m missing something, or I don't see the point about pathfix.
> >=20
> > It is not a matter of path, but rather allowing the ports tree to handle
> > properly all kind of library name, right now we have some false limitat=
ion and
> > library name collision because we wrongly rely on ldconfig -r.
> >=20
> > we have lots of patches so convert library names to a format
> > libname.so.asinglenumber, just for the sake of a technical limitation o=
f the
> > ports tree.
> >=20
> > That is what I m trying to fix.
> >=20
> > regards,
> > Bapt
> >=20
>=20
> Sorry, I was meaning USE_GNOME=3Dltverhack not gnomehack ...
>=20
> for example in www/neon we use it to change libneon.so.29 to libneon.so.27
>=20
> I haven't tested what is the result with a library that comes with so.x.x
> but maybe ltverhack works also there.
>=20

That is exactly the kind of hacks I do want do eliminate.

regards,
Bapt

--ZJcv+A0YCCLh2VIg
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)

iEYEARECAAYFAlG6Em8ACgkQ8kTtMUmk6EwNKACeLPHHoF2giGN/lRD8Hi5ZgQO0
4nMAoKmeURXrYB8jXR/uwycJ2giks4az
=JIed
-----END PGP SIGNATURE-----

--ZJcv+A0YCCLh2VIg--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130613184151.GD44980>