Re: Lib directory setup

[Doug McCorkle]

Hey Jan,

Thanks for your feedback and interest in this issue. Unfortunately I believe that checking the pointer size is not a reasonable way to determine which directory to use for the library install locations. I will outline my reasons below.

First, we initially ran into this problem when working with newer versions of ubuntu:

https://wiki.ubuntu.com/MultiarchSpec

You will notice that they have an intricate set of rules for how library directories get named. The current implementation supports this process well.

Second, just because a linux system is a 64 bit architecture does not mean that the package manager deposits 64 bit libraries in a lib64 directory. We work with SLES and openSUSE quite a bit and I know that 64 bit libraries get stored in a lib directory. This method appropriately detects when to use a lib64 directory for a given kernel.

Third, on macs the lib directory is used by default for 64 bit libraries. This implementation handles this case as well.

Fourth, while "Windows is totally stupid" might be true the standard that the broader development community has taken on this issue is that there is no lib64 directory. I think making osgBullet and osgWorks be philosophically correct is not something we want to do. In general it makes it more difficult for others to work with our projects.

Fifth, Paul and I are currently working with a couple of libraries that enforce a library install location based on the test that your are proposing and it ends up being somewhat of a hassle to deal with on the packaging, deployment, and integration front because it is different than the majority of libraries that we deal with.

Hopefully those reasons help you understand where we are coming from on this issue.

Doug


On Jun 19, 2013, at 10:29 AM, Paul Martz <skewm...@gmail.com> wrote:

> I'm content to let you and Doug bash this out. Though I would suggest we take the discussion to osgworks-users where the reasoning and conclusions will be archived.
>
>
> On Wed, Jun 19, 2013 at 9:27 AM, Paul Martz <skewm...@gmail.com> wrote:
> If I understand Doug's change correctly, you should be able to set CMAKE_INSTALL_LIBDIR to "lib64" and get the behavior you need. Is that not correct?
>
>
> On Wed, Jun 19, 2013 at 9:17 AM, Jan Ciger <jan....@gmail.com> wrote:
> Hello again,
>
> On Wed, Jun 19, 2013 at 4:59 PM, Paul Martz <skewm...@gmail.com> wrote:
> > Hey Doug -- Thanks for your recent commit. This works fine for me on 64-bit
> > Windows.
> >
> > Jan -- Doug submitted a follow-up change that uses more conventional CMake
> > rules for determining the names of the bin and lib directories. Can you
> > please give this a try and let us know how it works? Thanks.
>
> I have checked what the OSG build defines on Windows and unfortunately
> the fix is not correct.
>
> The code below which was introduced by Dough ignores Linux completely.
> I believe the CMAKE_INSTALL_LIBDIR is set to "lib" by default. It must
> be set explicitly to "lib64" on 64bit Linux if compiling for the 64bit
> ABI - that's why the pointer size test, because Linux supports both
> ABIs.
>
> I have tried to use the CMAKE_INSTALL_LIBDIR before, thinking that the
> correct directory will be selected based on the ABI, but it isn't the
> case. Not sure whether that is a gcc or CMake feature or bug. Also in
> Windows, when I am building for 64bits, the CMAKE_INSTALL_LIBDIR is
> not defined, just checked my OSG build for it. It should be probably
> "x64" to not mix 32bit and 64bit DLLs - Windows is totally stupid and
> will happily attempt to load a 32bit DLL into a 64bit binary, causing
> a crash, but that is another issue.
>
> if(NOT DEFINED CMAKE_INSTALL_LIBDIR)
> if(WIN32)
> set(CMAKE_INSTALL_LIBDIR bin)
> else(WIN32)
> set(CMAKE_INSTALL_LIBDIR lib)
> endif(WIN32)
> endif(NOT DEFINED CMAKE_INSTALL_LIBDIR)
>
> Regards,
>
> Jan
>
>
>
> --
> Paul Martz
> Skew Matrix Software LLC
>
>
>
> --
> Paul Martz
> Skew Matrix Software LLC

[Paul Martz]

Discussion on the cmake mail list appears to confirm that use of GNUInstallDirs and CMAKE_INSTALL_LIBDIR (as in our svn trunk HEAD) is the right approach:

http://www.cmake.org/pipermail/cmake/2011-August/045718.html

Is there a good reason why we should depart from the CMake project's advice regarding this?

On Wed, Jun 19, 2013 at 11:05 AM, Jan Ciger <jan....@gmail.com> wrote:

Hello Doug,

On Wed, Jun 19, 2013 at 6:11 PM, Doug McCorkle <doug.m...@gmail.com> wrote:
> Hey Jan,
>
> Thanks for your feedback and interest in this issue. Unfortunately I believe that checking the pointer size is not a reasonable way to determine which directory to use for the library install locations. I will outline my reasons below.
>
> First, we initially ran into this problem when working with newer versions of ubuntu:
>
> https://wiki.ubuntu.com/MultiarchSpec
>
> You will notice that they have an intricate set of rules for how library directories get named. The current implementation supports this process well.

Honestly, I don't really care much about Ubuntu. They seem to be very
keen on simply breaking whatever standard there is (even when for a
potentially good reason) without talking to anyone, as if the only
Linux around was Ubuntu. Lot of software needs to be packaged and
compiled for Ubuntu and then for "everyone else" thanks to their
policies and design decisions. FHS is perhaps old and insufficient,
but ignoring it and fragmenting the ecosystem won't make the situation
any better.

>
> Second, just because a linux system is a 64 bit architecture does not mean that the package manager deposits 64 bit libraries in a lib64 directory. We work with SLES and openSUSE quite a bit and I know that 64 bit libraries get stored in a lib directory. This method appropriately detects when to use a lib64 directory for a given kernel.

Well, that doesn't work for ex. on my Mageia 3, that was the reason
why the patch was submitted in the first place. I agree, it could be
distro-specific issue, but now we have OSG storing its stuff in lib64,
osgWorks/osgBullet in lib, etc. I don't see that exactly as an
improvement.

Furthermore, if I wanted to have both 32bit and 64bit binaries
side-by-side, I cannot. I have to install under different prefixes.

>
> Third, on macs the lib directory is used by default for 64 bit libraries. This implementation handles this case as well.

I am not going to comment on Mac, I am not familiar with their way of
building things.

>
> Fourth, while "Windows is totally stupid" might be true the standard that the broader development community has taken on this issue is that there is no lib64 directory. I think making osgBullet and osgWorks be philosophically correct is not something we want to do. In general it makes it more difficult for others to work with our projects.

That Windows comment was an aside, I am certainly not proposing using
"lib64" there. However, you will notice that e.g. Microsoft tools,
OpenCV and others use "x64" for 64bit libraries/binaries, because you
can have dual 32bit/64bit installs and having everything (headers,
docs, etc.) duplicated in separated folders is simply not practical.
It also makes it a lot simpler to set up PATH on Windows to the right
version of the binaries - in Linux you can have both architectures in
the same LD_LIBRARY_PATH and the linker will ignore the ones for the
wrong arch but in Windows you will get a crash.

>
> Fifth, Paul and I are currently working with a couple of libraries that enforce a library install location based on the test that your are proposing and it ends up being somewhat of a hassle to deal with on the packaging, deployment, and integration front because it is different than the majority of libraries that we deal with.

Fair enough, but keep in mind that you are breaking things for others
who do not use the same convention, unfortunately. E.g. CMake handles
looking up the libraries in lib/lib64 automatically - it tries lib
first and then looks in lib64. I do wonder how you handle packaging
and deployment of OSG itself too.

Regards,

Jan

[Doug McCorkle]

On Jun 19, 2013, at 12:05 PM, Jan Ciger <jan....@gmail.com> wrote:

> Hello Doug,

>
> On Wed, Jun 19, 2013 at 6:11 PM, Doug McCorkle <doug.m...@gmail.com> wrote:

>> Hey Jan,
>>
>> Thanks for your feedback and interest in this issue. Unfortunately I believe that checking the pointer size is not a reasonable way to determine which directory to use for the library install locations. I will outline my reasons below.
>>
>> First, we initially ran into this problem when working with newer versions of ubuntu:
>>
>> https://wiki.ubuntu.com/MultiarchSpec
>>
>> You will notice that they have an intricate set of rules for how library directories get named. The current implementation supports this process well.
>

> Honestly, I don't really care much about Ubuntu. They seem to be very
> keen on simply breaking whatever standard there is (even when for a
> potentially good reason) without talking to anyone, as if the only
> Linux around was Ubuntu. Lot of software needs to be packaged and
> compiled for Ubuntu and then for "everyone else" thanks to their
> policies and design decisions. FHS is perhaps old and insufficient,
> but ignoring it and fragmenting the ecosystem won't make the situation
> any better.
>

I do not disagree with your point here but what we have implemented supports this install case which is a requirement for some of our customers and developers.

>>
>> Second, just because a linux system is a 64 bit architecture does not mean that the package manager deposits 64 bit libraries in a lib64 directory. We work with SLES and openSUSE quite a bit and I know that 64 bit libraries get stored in a lib directory. This method appropriately detects when to use a lib64 directory for a given kernel.
>

> Well, that doesn't work for ex. on my Mageia 3, that was the reason
> why the patch was submitted in the first place. I agree, it could be
> distro-specific issue, but now we have OSG storing its stuff in lib64,
> osgWorks/osgBullet in lib, etc. I don't see that exactly as an
> improvement.
>
> Furthermore, if I wanted to have both 32bit and 64bit binaries
> side-by-side, I cannot. I have to install under different prefixes.

How about we just expose the cmake variable as a cached parameter and you can set it however choose but it will default to my current implementation?

>
>>
>> Third, on macs the lib directory is used by default for 64 bit libraries. This implementation handles this case as well.
>

> I am not going to comment on Mac, I am not familiar with their way of
> building things.
>
>>

>> Fourth, while "Windows is totally stupid" might be true the standard that the broader development community has taken on this issue is that there is no lib64 directory. I think making osgBullet and osgWorks be philosophically correct is not something we want to do. In general it makes it more difficult for others to work with our projects.
>

> That Windows comment was an aside, I am certainly not proposing using
> "lib64" there. However, you will notice that e.g. Microsoft tools,
> OpenCV and others use "x64" for 64bit libraries/binaries, because you
> can have dual 32bit/64bit installs and having everything (headers,
> docs, etc.) duplicated in separated folders is simply not practical.
> It also makes it a lot simpler to set up PATH on Windows to the right
> version of the binaries - in Linux you can have both architectures in
> the same LD_LIBRARY_PATH and the linker will ignore the ones for the

> wrong arch but in Windows you will get a crash.
>
I to am aware of a library that uses lib64 for windows. I am just pointing out that it is not the norm.

>>
>> Fifth, Paul and I are currently working with a couple of libraries that enforce a library install location based on the test that your are proposing and it ends up being somewhat of a hassle to deal with on the packaging, deployment, and integration front because it is different than the majority of libraries that we deal with.
>

> Fair enough, but keep in mind that you are breaking things for others
> who do not use the same convention, unfortunately. E.g. CMake handles
> looking up the libraries in lib/lib64 automatically - it tries lib
> first and then looks in lib64. I do wonder how you handle packaging
> and deployment of OSG itself too.

I repackage it to support my installation requirements.

In general supporting dual installs of 32 and 64 bit by just changing the lib directory is dangerous in my opinion. There are some libraries where headers can change based on the platform that is targeted and of course you have executables that are in the mix as well. For example with osgWorks all of the utility executables cannot be installed with the same installation prefix for different architectures.

Doug