On 30/12/2013 12:21, O. Hartmann wrote:
> On Mon, 30 Dec 2013 12:10:40 +0200
> Kalle Raiskila <[email protected]> wrote:
>
>> Eh, it seems we have discussed this previously already :)
>>
>> https://github.com/pocl/pocl/commit/5ab2b9ace0f5e666244fd9d7f37c62b828f9cf36
>>
>>
>> Pekka wrote on 2013-12-26:
>>
>>> The full library file name in the .icd file was there, IIRC,
>>> to be easily able to use multiple pocl's at the same time
>>> (e.g. for benchmarking reasons), but we can change that to use
>>> the symlink name if that seems to cause problems and the
>>> symlink doesn't.
>>
>> According to the commit log, the version number popped up initially
>> with a patch from Vincent in
>>
>> https://github.com/pocl/pocl/commit/ae6c28ba2c8ad119de4ae904b5eeb529f335f628
>>
>> The comment line:
>> * Load the full soname (not the lib*.so that can be not installed
>> because it is in the -dev package)
>> seems to be relevant to this change, but I'm not sure I understand
>> what is meant here.
>>
>> I'd prefer the pocl.icd to have just "@libdir@/libpocl.so" in it.
>>
>> Drop the ".VER" because:
>> - it breaks on BSD :)
>> - several concurrent versions of pocl is a bit of a rare use case (?)
>> - if several versions are concurrently installed, several .icd files
>> are needed -> user needs to edit the .icd files anyways.
>> - I haven't seen it break without the .VER anywhere I've tried
>>
>> And the motivation for having the full path with "@libdir@/" is just
>> popular demand. For multiarch packaging, it should be removed, of
>> course. If package maintainers would prefer, this could be made to
>> a ./configure switch, say "--enable-multiarch"?
I do not think so. I think "@libdir@/" is right in the general case.
Packagers that will install pocl in multiarch system directory can
very easily patch the icd file. In my opinion, no need to add
complexity (configure option) in upstream code for such a particular
use case.
>> kalle
>
> Sorry for the tardy reply.
>
> I'm quite sure that the concept in POCL is right, but I need to find
> out why the ports framework of FreeBSD's ports system is bumping the
> version number up again.
I agree here. The .so filename should only be used for (direct) linking
with a shared library. In debian, lintian complains when .so files are
added into a library package that is not a development package (-dev).
For pocl use case, I'm not sure what is better between SONAME
(libpocl.so.X) or full library name (libpocl.so.X.Y). In the Debian
package, it will be the SONAME as I do not see any reason to change
the icd file when the pocl library is upgraded into a compatible version.
But the icd file will be patched (to remove @libdir@) so I can change this
too. When developing, it can be better to have the full name to know
which version of pocl is really used. I've no strong opinion here.
Regards,
Vincent
> I figured out that I have used a self-made tarball of a recent GIT
> repositorium (0.10-pre) and not the recent upcoming 0.9-POCL sources.
>
> Regards,
> Oliver
>
>
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> pocl-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/pocl-devel
>
--
Vincent Danjean Adresse: Laboratoire LIG - Bât. INRIA Rhône-Alpes
Téléphone: +33 4 76 61 55 10 655 avenue de l'Europe
Fax: +33 4 76 61 52 52 Montbonnot Saint Martin
Email: [email protected] 38334 Saint-Ismier cedex
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
pocl-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pocl-devel
