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<name>.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<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 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"
