Menu
▾
▴
Re: [Playerstage-developers] Installing Libraries on 64 bit systems
|
From: John H. <jh...@ee...> - 2010-06-30 13:07:41
|
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 >>>>>> Pla...@li... >>>>>> 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 >>>>> Pla...@li... >>>>> 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 >>>> Pla...@li... >>>> 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 >>> Pla...@li... >>> 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 >> Pla...@li... >> 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 > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > |