Re: Installing Libraries on 64 bit systems

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