Re: Re: Ogle on x86-64 build fix
Matthias Saou <thias@spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net> Fri, 10 Dec 2004 21:36:11 +0100
| Newsgroups | gmane.comp.video.ogle.devel |
|---|---|
| Message-ID | <20041210213611.09fb854d@python2> |
H}kan Hjort wrote : > I'm not sure how other applications deal with this, my personal oppinion > is that the whole system is just broken. Libraries are installed in > /lib subdirectories, not /lib64. Well, with autotools, they're installed in whatever --libdir was specified at compile time. Later on though, something like a "foo-config --libs" script to call or a pkgconfig .pc file are needed to avoid checking all possible locations. > Had -m64 been passed to the compiler/linker then I could possibly > understand why, but again I think it would be haveen better handled by > the compiler or linker. If the linker knows thatfrom the ELF heades > what is a 32 respective 64 bit version why does it need to be told in > the first place. Welcome to the wonderful world of "multilib" :-) I'm sure some people have been driven insane by this already! The "problem" being that x86_64 systems can also run x86 binaries, thus some (many?) libraries can be present in both 32bit and 64bit forms and provide the flexibility of running both native optimized code and legacy x86 binaries. Anyway, the point is that you can have a whole native x86_64 system, while keeping x86 "compatibility" for binary programs, may it be because they're proprietary and only available in that form, or by "laziness" of recompiling them when no native 64bit build is available. > There is already support for (non-)threaded, (no-)cmov etc versions > of .so files. Perhaps there this is an easier issue though... I guess you mean for example the /usr/lib/sse2 directory on Fedora Core? That's a different matter IMHO, which arises when the program doesn't properly runtime detect CPU optimizations, or when compiling in the opts vs. letting runtime detection enable them induces a performance cost. > That a side, I'd appreciate tips on how this is solved in other > configure.in/ac files. > > The lib vs lib64 isn't really based on host os but rather if gcc/ld > defaults to (or has been given extra flags) to produce 32- or 64-bit > code. > > www.gnu.org seems to be down, so I can't even checked what if anything > the autoconf guys have to say on this. Maybe pkgconfig-enabling libdvdread and ogle would make things much easier? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.9-1.681_FC3.r300 Load : 0.35 0.38 0.36