Re: Installing Libraries on 64 bit systems

On Wed, 30 Jun 2010, Geoffrey Biggs wrote:

> I was going to say we should put them in lib64 by default on such
> systems, but if ubuntu is doing the opposite...
>
> An option for detection logic would be to look specifically for a
> /usr/lib64 or /usr/lib32 directory. I'm not aware of any systems that
> don't at least use some form of /usr/lib (Paul will probably know), so
> we should be able to make an educated guess from the presence of one or
> the other where to put the libraries.
>
> Geoff
>

Little walk through my 64-bit systems (/usr directory):

Gentoo Linux on double Opteron:
lrwxrwxrwx   1 root root     5 2008-03-12  lib -> lib64
drwxr-xr-x   4 root root  4096 2009-08-13  lib32
drwxr-xr-x  59 root root 36864 02-02 12:45 lib64
(lib64 contains much more libs than lib32, never compiled Player on this 
one yet)

Scientific Linux 5.2 (derived from RHEL5) on Core2Extreme:
drwxr-xr-x  99 root root  73728 maj 24 11:04 lib
drwxr-xr-x 137 root root 131072 cze 14 18:20 lib64
(lib64 contains much more libs than lib, Player runs 64-bit nicely)

Fedora 9 on double G5:
drwxr-xr-x 161 root root 90112 lip 20  2009 lib
drwxr-xr-x  31 root root 28672 lip 19  2009 lib64
(lib contains much more libs than lib64, I never compiled Player on this, 
I doubt there's sufficient 64-bit libs to build it as 64-bit binary)

Solaris 10 on quadruple UltraSparc:
drwxr-xr-x 126 root     bin        36864 mrz 13 08:56 lib
let's go into /usr/lib and see:
lrwxrwxrwx   1 root     root           1 mrz 27  2009 32 -> .
lrwxrwxrwx   1 root     root           7 mrz 27  2009 64 -> sparcv9
(1340 files in /usr/lib, 32-bit libraries, 636 files in /usr/lib/64, 
64-bit libraries; Player compiled automatically as 32-bit, maybe I'll try 
to force building 64-bit binary, I need to figure out how)
There's no /usr/lib/64 nor /usr/lib/32 on previously inspected Linux 
machines.

Once I had NetBSD and then OpenBSD on that UltraSparc machine, I'm not 
100% sure but I remember that all userland was 64-bit and all libraries in 
/usr/lib were 64-bit (so there was no multilib). From the other hand I had 
Gentoo Linux on that UltraSparc machine for longer while, it was 64-bit 
kernel while all userspace was 32-bit, /usr/lib contained 32-bit 
libraries, no /usr/lib64 library, some 64-bit libs provided by gcc so 
kernel and simple "Hello world" programs could be compiled as 64-bit 
binaries.
Also for a short while I had Aurora Linux (Fedora derived) on UtraSparc, 
it had multilib, however most of the userland was 32-bit, directories were 
as in Scientific Linux/RHEL and Fedora.
For a while I had MacOSX on G5 (now replaced by Fedora 9), AFAIR most of 
the userland was 32-bit, now I don't remember the directory structure.

Paul

> On 30/06/10 12:59, Rich Mattes wrote:
>> I was afraid you were going to say Ubuntu ;).  Given its pervasiveness,
>> it might be a better idea to default to lib unless otherwise specified,
>> but I'd like to keep the conversation going for a little while in case
>> anyone else has another opinion.  I'll work on patching the buildsystem
>> to expose an option in the meantime.
>>
>> Rich
>>
>> On 06/29/2010 11:29 PM, John Hoare wrote:
>>> My apologies, I meant to put that I'm using Ubuntu 10.04. I don't know
>>> if theres any way to determine where the system "wants" 64 bit
>>> libraries to be installed. We could put something in where we try to
>>> detect the distribution and set the suffix appropriately, but this
>>> sounds like a big pain that would be difficult to keep maintained.
>>>
>>> I do think there should be at least some way for the user to override
>>> what the CMake logic has chosen.
>>>
>>> -John
>>>
>>> On 06/29/2010 11:19 PM, Rich Mattes wrote:
>>>> Hi John,
>>>>
>>>> I'm curious as to which flavor of Linux you're working with.  I'm the
>>>> one responsible for for the below 64 bit logic; I'm currently working
>>>> with Fedora and I submitted the below patch when I was creating the
>>>> rpm package.  I think exposing the library install directory in some
>>>> fashion is probably the easiest way to go, that way you can override
>>>> the detection logic most easily.  I'm leaning towards creating a
>>>> -DLIB_SUFFIX option, but that's only because Fedora's buildsystem
>>>> will add that particular flag to the cmake command line on 64 bit
>>>> architectures.  The patch you included would accomplish the same thing.
>>>>
>>>> The question then becomes, should we default to a multilib
>>>> installation on 64 bit architectures, or should we default to
>>>> installing to "lib" unless the setting is overridden?  Since each
>>>> distribution tends to handle multilib differently, we should probably
>>>> find a setting that most Linuxes can deal with.  To be honest, with
>>>> the lib suffix exposed we really don't need the fancy architecture
>>>> detection logic at all   I lean towards defaulting to lib64 on 64 bit
>>>> systems.
>>>>
>>>> I'm interested in hearing opinions for or against installing to lib64
>>>> by default on 64bit linux.
>>>>
>>>> Rich
>>>>
>>>> On 06/29/2010 10:10 PM, John Hoare wrote:
>>>>> Hi,
>>>>>
>>>>> It's been discussed a bit before about where libraries exist on
>>>>> different systems. Some unixes have them in a lib64 directory and
>>>>> some have them in the lib directory (and 32 bit libs in lib32).
>>>>> Right now, as far as I can tell, it does not give you a choice when
>>>>> you're building player, the libraries have to go into lib64.
>>>>>
>>>>> The issue for me is, that lib64 is not in the system's library
>>>>> search path, so when I compile player, and link against player, when
>>>>> I try to run any libraries linked against player's I get a library
>>>>> not found error. My solution to this was to just expose the
>>>>> PLAYER_LIBRARY_INSTALL_DIR CMake variable so that you can change
>>>>> lib64 to lib if you so desire.
>>>>>
>>>>> Is there a better way to do this, or is this the way it should be
>>>>> done. I've attached what I've done as a patch (it's quite simple) if
>>>>> anyone is interested.
>>>>>
>>>>> I apologize if this specific topic has been discussed before, I
>>>>> searched for a bit and couldn't find anything, only the discussion
>>>>> about multilib linux (Player SVN trunk: Problem with playerc++ on
>>>>> multilib Linux/x86_64)
>>>>>
>>>>> Thanks,
>>>>> John Hoare
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> This SF.net email is sponsored by Sprint
>>>>> What will you do first with EVO, the first 4G phone?
>>>>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Playerstage-developers mailing list
>>>>> [email protected]
>>>>> https://lists.sourceforge.net/lists/listinfo/playerstage-developers
>>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> This SF.net email is sponsored by Sprint
>>>> What will you do first with EVO, the first 4G phone?
>>>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>>>>
>>>>
>>>> _______________________________________________
>>>> Playerstage-developers mailing list
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/playerstage-developers
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by Sprint
>>> What will you do first with EVO, the first 4G phone?
>>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>>>
>>>
>>> _______________________________________________
>>> Playerstage-developers mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/playerstage-developers
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>>
>>
>>
>> _______________________________________________
>> Playerstage-developers mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/playerstage-developers
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Playerstage-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/playerstage-developers
>

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first