 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
