Re: [CFT] Fixing/changing LIB_DEPENDS
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 installed
> >>> 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.so[.number], while we have no technical limitation to
> >>> enforce this
> >>> form and it is more and more common to find libraries in the following
> >>> form:
> >>> lib.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 current
> >>> one:
> >>> LIB_DEPENDS= 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
> >>> validate 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.patch
> >>>
> >>> This idea behind this patch is on mid/long term to remove the other
> >>> LIB_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 notation
> >> For example pcre.3:... becomes pcre:...
> >>
> >> Isn't this something that can be handled with some additional code in
> >> pathfix?
> >>
> >> --
> >> regards,
> >> olli
> >>
> >
> > Either I m missing something, or I don't see the point about pathfix.
> >
> > 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 limitation
> > and
> > library name collision because we wrongly rely on ldconfig -r.
> >
> > we have lots of patches so convert library names to a format
> > libname.so.asinglenumber, just for the sake of a technical limitation of the
> > ports tree.
> >
> > That is what I m trying to fix.
> >
> > regards,
> > Bapt
> >
>
> Sorry, I was meaning USE_GNOME=ltverhack not gnomehack ...
>
> for example in www/neon we use it to change libneon.so.29 to libneon.so.27
>
> I haven't tested what is the result with a library that comes with so.x.x
> but maybe ltverhack works also there.
>
That is exactly the kind of hacks I do want do eliminate.
regards,
Bapt
pgpQ516NdoMdb.pgp
Description: PGP signature
Re: [CFT] Fixing/changing LIB_DEPENDS
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 installed
>>> 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.so[.number], while we have no technical limitation to enforce
>>> this
>>> form and it is more and more common to find libraries in the following form:
>>> lib.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 current
>>> one:
>>> LIB_DEPENDS=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
>>> validate 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.patch
>>>
>>> This idea behind this patch is on mid/long term to remove the other
>>> LIB_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 notation
>> For example pcre.3:... becomes pcre:...
>>
>> Isn't this something that can be handled with some additional code in
>> pathfix?
>>
>> --
>> regards,
>> olli
>>
>
> Either I m missing something, or I don't see the point about pathfix.
>
> 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 limitation and
> library name collision because we wrongly rely on ldconfig -r.
>
> we have lots of patches so convert library names to a format
> libname.so.asinglenumber, just for the sake of a technical limitation of the
> ports tree.
>
> That is what I m trying to fix.
>
> regards,
> Bapt
>
Sorry, I was meaning USE_GNOME=ltverhack not gnomehack ...
for example in www/neon we use it to change libneon.so.29 to libneon.so.27
I haven't tested what is the result with a library that comes with so.x.x
but maybe ltverhack works also there.
--
regards,
olli
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: [CFT] Fixing/changing LIB_DEPENDS
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 installed
> > 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.so[.number], while we have no technical limitation to enforce
> > this
> > form and it is more and more common to find libraries in the following form:
> > lib.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 current
> > one:
> > LIB_DEPENDS=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
> > validate 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.patch
> >
> > This idea behind this patch is on mid/long term to remove the other
> > LIB_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 notation
> For example pcre.3:... becomes pcre:...
>
> Isn't this something that can be handled with some additional code in pathfix?
>
> --
> regards,
> olli
>
Either I m missing something, or I don't see the point about pathfix.
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 limitation and
library name collision because we wrongly rely on ldconfig -r.
we have lots of patches so convert library names to a format
libname.so.asinglenumber, just for the sake of a technical limitation of the
ports tree.
That is what I m trying to fix.
regards,
Bapt
pgpDHh_IJMMgs.pgp
Description: PGP signature
Re: [CFT] Fixing/changing LIB_DEPENDS
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 installed 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.so[.number], while we have no technical limitation to enforce
> this
> form and it is more and more common to find libraries in the following form:
> lib.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 current one:
> LIB_DEPENDS= 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 validate
> 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.patch
>
> This idea behind this patch is on mid/long term to remove the other
> LIB_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 notation
For example pcre.3:... becomes pcre:...
Isn't this something that can be handled with some additional code in pathfix?
--
regards,
olli
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
[CFT] Fixing/changing LIB_DEPENDS
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 installed 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.so[.number], while we have no technical limitation to enforce this
form and it is more and more common to find libraries in the following form:
lib.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 current one:
LIB_DEPENDS=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 validate 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.patch
This idea behind this patch is on mid/long term to remove the other LIB_DEPENDS
forms.
I do plan to commit this on next friday 2013-06-21.
regards,
Bapt
pgpoq2965CClq.pgp
Description: PGP signature
