Re: Installing Libraries on 64 bit systems

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

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