Re: Installing Libraries on 64 bit systems

  I added a CMake option (LIB_SUFFIX) that will override the 
architecture detection.  If you specify -DLIB_SUFFIX="", libraries will 
be installed to cmake_install_prefix/lib, and -DLIB_SUFFIX=64 will move 
the installation target to cmake_install_prefix/lib64.  If you don't 
specify anything, it'll fall back to the architecture detection, and 
will install to cmake_install_prefix/lib unless a linux ppc64 or linux 
x86_64 host is detected.  I modified the command line output when you 
run cmake, so it shows the full install path.

Changes were made in svn trunk.  Sorry it took me so long!

Rich

On 06/30/2010 09:07 AM, John Hoare wrote:
> Okay, I'm going to have to eat my words now.
>
> I looked again at Ubuntu, because of how many of Paul's systems have a
> lib64. It turns out ubuntu is the same way (lib64 with a lib symbolic link)
>
> rwxr-xr-x 294 root root 132K 2010-06-21 12:17 lib
> drwxr-xr-x  35 root root  32K 2010-02-21 20:29 lib32
> lrwxrwxrwx   1 root root    3 2009-10-15 15:53 lib64 ->  lib
>
> The problem I was having, was that I was installing player into
> /usr/local, which did not have this lib symbolic link made, so it didn't
> find the libs in lib64, of course if I make this symbolic link then
> everything works fine.
>
> I don't think player should be responsible for creating this symbolic
> link, so perhaps this should just be a wiki/faq entry instead.
>
> Oops,
> -John
>
> On 6/30/10 5:59 AM, Paul Osmialowski wrote:
>> 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
>> _______________________________________________
>> 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 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev