POV-Ray : Newsgroups : povray.unix : Some help needed Server Time
3 Dec 2024 22:18:17 EST (-0500)
  Some help needed (Message 6 to 15 of 15)  
<<< Previous 5 Messages Goto Initial 10 Messages
From: clipka
Subject: Re: Some help needed
Date: 20 May 2017 04:05:20
Message: <591ff8c0$1@news.povray.org>
Am 18.05.2017 um 20:25 schrieb clipka:

> Currently, our approach at identifying the version of the installed
> OpenEXR library is based on the `pkg-config` tool, which does not seem
> to be available on all systems (example: Mac OS X darwin 15.6.0).

I have to correct myselfg on this one: pkg-config apparently /is/
available on Mac OS X darwin 15.6.0; but for some reason it fails to
work properly with the OpenEXR library package available for that system.


Post a reply to this message

From: William F Pokorny
Subject: Re: Some help needed
Date: 20 May 2017 09:24:46
Message: <5920439e$1@news.povray.org>
On 05/20/2017 04:05 AM, clipka wrote:
> Am 18.05.2017 um 20:25 schrieb clipka:
> 
>> Currently, our approach at identifying the version of the installed
>> OpenEXR library is based on the `pkg-config` tool, which does not seem
>> to be available on all systems (example: Mac OS X darwin 15.6.0).
> 
> I have to correct myselfg on this one: pkg-config apparently /is/
> available on Mac OS X darwin 15.6.0; but for some reason it fails to
> work properly with the OpenEXR library package available for that system.
> 
In my digging it seemed like occasionally folks had to update an 
environment variable PKG_CONFIG_PATH to point to the location of a 
packages particular *.pc files. They can be in different locations and 
the ones getting picked up on linux for gnu compiles seem mostly located 
in :

/usr/lib/x86_64-linux-gnu/pkgconfig

with:

/usr/lib/x86_64-linux-gnu/pkgconfig/OpenEXR.pc

and

/usr/lib/x86_64-linux-gnu/pkgconfig/IlmBase.pc

being the two used for openexr. I suppose on other systems, compilers 
where the *.pc files get picked up might change. If you find a different 
location is needed for Mac OS X darwin 15.6.0 etc, perhaps the easiest 
fix is our setting PKG_CONFIG_PATH to point to it?

You can check the current defaulted library paths being used to find 
*.pc files with the command:

     pkg-config --variable pc_path pkg-config

One of the reasons I now find myself unwilling to duplicate the 
pkg_config function is that it is not all that simple in total. I think 
I'm going to bail on this work if you insist on a pkg-config like 
solution we own.

Aside: There is a perl script (cpan pm package) called, if I remember, 
ppkg-config that some use as an alternative to pkg-config though it was 
all that clear to me why. I've not looked at it, but if you really want 
to avoid pkg-config starting there with the idea we'd ship such a script 
ourselves is perhaps a place to start.

Aside2: A while back I tried to do a static compile with --enable-static 
and it failed to link a library other than openexr. I wonder now if I 
could find the link flags needed to get this going with "pkg-config 
--static".

Where do you want to go with this?

I'll hold off making any further updates pending your answer.

Bill P.


Post a reply to this message

From: William F Pokorny
Subject: Re: Some help needed
Date: 20 May 2017 09:34:57
Message: <59204601$1@news.povray.org>
On 05/20/2017 03:42 AM, clipka wrote:
> Am 19.05.2017 um 21:35 schrieb William F Pokorny:
> 
>> Got back to this a while ago. The more I dig the more I think if the
>> pkg-config command and its infrastructure exists, it should be used first.
>>
>> In fact for best reliability, the pkg-config mechanism should perhaps be
>> used first for all our packages when available. The necessary .pc files
>> exists for the Simple DirectMedia Layer library too it turns out.
> 
> Are you sure about this?
> 
> To my knowledge, the pkg-config mechanism tells you what packages are
> installed via a Linux distribution's package management, such as apt.
> 
> However, if the user chooses to install a different version of a library
> locally, using environment variables or parameters to `./configure` to
> point the compiler there, then my guess is that relying on pkg-config
> would seriously screw up things.
> 
> 
> Unless pkg-config reliably addresses that issue, in my opinion our first
> attempt should be to try and pry the relevant information from the very
> files that will be accessed during compilation, i.e. the header files.
> 

I'm unsure at the moment how the other version mechanism works but would 
be a little surprised if pkg-config doesn't have a mechanism to handle 
it. I'll do a little more digging on this and see what I can turn up.

We can certainly hard code flags to what works now if you want to do this.

Bill P.


Post a reply to this message

From: clipka
Subject: Re: Some help needed
Date: 20 May 2017 09:38:19
Message: <592046cb$1@news.povray.org>
Am 20.05.2017 um 15:24 schrieb William F Pokorny:

> One of the reasons I now find myself unwilling to duplicate the
> pkg_config function is that it is not all that simple in total. I think
> I'm going to bail on this work if you insist on a pkg-config like
> solution we own.

What would be the point in duplicating pkg-config in the first place?

We're not using pkg-config (or anything similar) for the other
libraries, so I see no point why we should rely on it for OpenEXR.


Post a reply to this message

From: William F Pokorny
Subject: Re: Some help needed
Date: 20 May 2017 10:12:26
Message: <59204eca$1@news.povray.org>
On 05/20/2017 09:34 AM, William F Pokorny wrote:
> On 05/20/2017 03:42 AM, clipka wrote:
>> Am 19.05.2017 um 21:35 schrieb William F Pokorny:
>>
>>> Got back to this a while ago. The more I dig the more I think if the
>>> pkg-config command and its infrastructure exists, it should be used 
>>> first.
>>>
>>> In fact for best reliability, the pkg-config mechanism should perhaps be
>>> used first for all our packages when available. The necessary .pc files
>>> exists for the Simple DirectMedia Layer library too it turns out.
>>
>> Are you sure about this?
>>
>> To my knowledge, the pkg-config mechanism tells you what packages are
>> installed via a Linux distribution's package management, such as apt.
>>
>> However, if the user chooses to install a different version of a library
>> locally, using environment variables or parameters to `./configure` to
>> point the compiler there, then my guess is that relying on pkg-config
>> would seriously screw up things.
>>
>>
>> Unless pkg-config reliably addresses that issue, in my opinion our first
>> attempt should be to try and pry the relevant information from the very
>> files that will be accessed during compilation, i.e. the header files.
>>
> 
> I'm unsure at the moment how the other version mechanism works but would 
> be a little surprised if pkg-config doesn't have a mechanism to handle 
> it. I'll do a little more digging on this and see what I can turn up.
> 
> We can certainly hard code flags to what works now if you want to do this.
> 
> Bill P.

It looks like where multiple libraries can exist in system space the 
library names must be unique and the *.pc prefixes must be unique and 
where you want other than the system default you must refer to the 
version by name when using pkg-config to get the compiler and linker 
flags to use.

When the libraries are installed in non-standard locations - say a user 
space often it seems the already mentioned PKG_CONFIG_PATH environment 
variable is used to put the users versions ahead of the any system ones. 
I suppose in our current set users would need to know to do this.

It looks like it is expected folks use the environment variable
PKG_CONFIG_LIBDIR to be when no system package *.pc information is to be 
used. Something you might do if say compiling on Ubuntu for another 
target system.

Bill P.


Post a reply to this message

From: William F Pokorny
Subject: Re: Some help needed
Date: 20 May 2017 10:30:47
Message: <59205317$1@news.povray.org>
On 05/20/2017 09:38 AM, clipka wrote:
> Am 20.05.2017 um 15:24 schrieb William F Pokorny:
> 
>> One of the reasons I now find myself unwilling to duplicate the
>> pkg_config function is that it is not all that simple in total. I think
>> I'm going to bail on this work if you insist on a pkg-config like
>> solution we own.
> 
> What would be the point in duplicating pkg-config in the first place?
> 
> We're not using pkg-config (or anything similar) for the other
> libraries, so I see no point why we should rely on it for OpenEXR.
> 

The reason to use pkg-config is to reliably get library compiler and 
linker flags for the system and libraries where the compile is happening.

We hard code flags today except with openexr and sdl where they are 
determined on the fly. If you want to hard code flags for openexr, make 
that call and I'll attempt to update the .m4 file using the flags I see 
being used today vie pkg-config.

My recommendation continues to be to fall back to such hard coding only 
when pkg-config doesn't exist or doesn't work.

Searching for the *.pc files in the many directories where they exist, 
reliably parsing them to figure out flags and the *.pc dependencies so 
we can reliably have flags current with the libraries is not a trivial 
task. I'm not myself going to do that work mostly because it looks to me 
to duplicate a significant function of pkg-config.

Bill P.


Post a reply to this message

From: clipka
Subject: Re: Some help needed
Date: 21 May 2017 16:54:22
Message: <5921fe7e$1@news.povray.org>
I think what we should do, in a nutshell, is the following:

- Inform the users that they may need the pkg-config package (if they
want to use OpenEXR).

- In the absence of pkg-config, or if pkg-config fails to come up with
any useful information, make a reasonable attempt to determine the
OpenEXR version in another manner, and make a reasonable guess at the
additional compiler and linker flags required (if any).

- Make sure our configure script contains a test to verify that the
OpenEXR library can be linked using the chosen compiler and linker flags.


I also wonder whether we should make our handling of libraries more
consistent, and make use of pkg-config for other libraries as well where
possible.

As a side note, I noticed that the automake tools apparently provide
dedicated macros to make use of pkg-config; those might be worth a
closer look, even if in the end we decide against them (their use seems
to be controversial due to some known issues, so if we decide to use
them nonetheless, we should clearly document those issues).


Post a reply to this message

From: dick balaska
Subject: Re: Some help needed
Date: 21 May 2017 17:39:25
Message: <5922090d$1@news.povray.org>
Am 2017-05-21 16:54, also sprach clipka:

> As a side note, I noticed that the automake tools apparently provide
> dedicated macros to make use of pkg-config;

I was surprised there was no m4 macro for openexr.
https://www.gnu.org/software/autoconf-archive/The-Macros.html

I wondered if maybe modifying ax_pkg_mico might be a starting point.
https://www.gnu.org/software/autoconf-archive/ax_pkg_mico.html


-- 
dik


Post a reply to this message

From: William F Pokorny
Subject: Re: Some help needed
Date: 22 May 2017 06:58:10
Message: <5922c442$1@news.povray.org>
On 05/21/2017 04:54 PM, clipka wrote:
> I think what we should do, in a nutshell, is the following:
> 
> - Inform the users that they may need the pkg-config package (if they
> want to use OpenEXR).
> 
> - In the absence of pkg-config, or if pkg-config fails to come up with
> any useful information, make a reasonable attempt to determine the
> OpenEXR version in another manner, and make a reasonable guess at the
> additional compiler and linker flags required (if any).
> 
> - Make sure our configure script contains a test to verify that the
> OpenEXR library can be linked using the chosen compiler and linker flags.
> 
> 
> I also wonder whether we should make our handling of libraries more
> consistent, and make use of pkg-config for other libraries as well where
> possible.
> 
> As a side note, I noticed that the automake tools apparently provide
> dedicated macros to make use of pkg-config; those might be worth a
> closer look, even if in the end we decide against them (their use seems
> to be controversial due to some known issues, so if we decide to use
> them nonetheless, we should clearly document those issues).
> 

Thanks for the guidance. I'll work this direction.

I think we should look to use pkg-config only where the library itself 
seems to support it with the necessary *.pc information. Though, hacking 
our own *.pc files where they are missing or inaccurate would be a 
possible path too I guess...

Yes, a test compile and test link with whatever flags we determine to 
use makes good sense.

FYI. It turns out pkg-config does provide the flags necessary to fix the 
--enable-static link issue with libtiff I mentioned somewhere in this 
thread. We are always using just

-ltiff

which "pkg-config --libs libtiff-4" returns too. If we ask for the 
static flags with: "pkg-config --libs --static libtiff-4" we get:

-ltiff -llzma -ljbig -ljpeg -lz -lm

where -llzma and -ljbig are unique to what we end up with today in the 
Makefiles and necessary for the static link to work. So, we have already 
one issue that using pkg-config should fix for many *nix based users.

I also got my hands on an old book on autoconf & automake yesterday, 
which I'll continue to look through today. I know a smidgen now about M4 
to the envy of millions. ;-)

Bill P.


Post a reply to this message

From: William F Pokorny
Subject: Re: Some help needed
Date: 22 May 2017 07:00:38
Message: <5922c4d6$1@news.povray.org>
On 05/21/2017 05:39 PM, dick balaska wrote:
> Am 2017-05-21 16:54, also sprach clipka:
> 
>> As a side note, I noticed that the automake tools apparently provide
>> dedicated macros to make use of pkg-config;
> 
> I was surprised there was no m4 macro for openexr.
> https://www.gnu.org/software/autoconf-archive/The-Macros.html
> 
> I wondered if maybe modifying ax_pkg_mico might be a starting point.
> https://www.gnu.org/software/autoconf-archive/ax_pkg_mico.html
> 
> 
Thanks for the pointers. I'd found the general archive link yesterday, 
but the site seemed to be having an issues and I could not get to it.

Just now your links OK & I'll take a look at the package you suggest first.

Bill P.


Post a reply to this message

<<< Previous 5 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.