Re: [Discuss-gnuradio] Binary packaging problems on x86_64

[Eric Blossom]

On Mon, Dec 19, 2005 at 08:05:07AM -0800, Larry Doolittle wrote:
> On Mon, Dec 19, 2005 at 09:16:10AM -0500, Greg Troxel wrote:
> > 
> > On NetBSD, ${libdir} always has native libraries, where native means
> > the instruction set and word size defined by the combination of
> > hardware and which kernel is being run.  Then, other libraries go in
> > /emul/foo, where foo can denote other operating systems or other
> > architectures.
> 
> > So, rather than Berndt adapting the package, GNU Radio should be
> > changed to only munge libdir on systems where such munging is the
> > convention, and the list sounds like most but not all GNU/Linux
> > systems.
> 
> At least not Debian Sarge, and Sid as of today.
> 
> > -  if test "$host_cpu" = "x86_64"; then
> > +  if test "$host_os" = "Linux" -a "$host_cpu" = "x86_64"; then
> > +    # XXX Debian may not use this convention.
> 
> In the spirit of autoconf, shouldn't this check behavior,
> instead of enumerating systems?
> 
> if test -d ${libdir}64; then ...
> 
>        - Larry

Seems like putting the native stuff where it's always been
(${libdir}) would have been an obvious win.  Perhaps it will
return to this.


Is this summary correct?

X86_64               64-bit             32-bit
------------------------------------------------------------
SuSE 9.3             ${prefix}/lib64    ${prefix}/lib
Mandriva 2006        ${prefix}/lib64    ${prefix}/lib
Gentoo               ${prefix}/lib64    ${prefix}/lib
Debian Sarge         ${prefix}/lib      <someplace else>
Debian Sid           ${prefix}/lib      <someplace else>
NetBSD               ${prefix}/lib      <someplace else>

I know that ${prefix}/lib* should really be ${libdir}, but I want to
be clear about the lib vs lib64 part.

Does anyone have any other data points?  Fedora Core, RedHat?

I assume that whatever we come up with is going to be subject to
change, until sanity is restored across the universe.

Perhaps a configure option --with-lib64 with the default picked "to
the best of our current knowledge" is workable.  This would allow the
user to fix it on the command line if our guess was wrong.  I'll post
this question to the GNU maintainers list.

Eric