On Nov 19, 2006, at 1:43 AM, David R. Morrison wrote:
> Dear fink developers,
>
> I solicit your comments on the proposals below to (1) change the
> storage location for 64bit libraries and formalize this into policy,
> and (2) add a new percent expansion to fink, one whose value would be
> dependent on some other things.
>
> The issue is the correct storage location for 64bit libraries. We've
> known for some time that 64bit libraries and 64bit executables are
> not compatible with 32bit ones, and a decision was reached last
> spring to store 64bit libraries in /sw/lib64 (analogous to some linux
> distributions). However, it has since been pointed out by Peter
> O'Gorman that gcc makes some assumptions about where 64bit libraries
> are being stored: either /sw/lib/ppc64 for powerpc hardware, or /sw/
> lib/x86_64 for intel hardware.
>
> Proposal #1 is that we use these storage locations for our 64bit
> libraries, and make that fink policy. (There are only two packages
> which have adopted the old scheme -- gmp-64bit and openmcl-64bit --
> and we would need to break binary compatibility for these by moving
> their shared libs in a upgrade. However, nothing depends on them,
> and they are only present in unstable.)
>
> To make packaging easier on multiple architectures, and in particular
> to make it easier to use the fink "variants" idea to package 64bit
> libraries and 32bit libraries in the same architecture, Proposal #2
> is to introduce a new percent expansion %lib which would behave as
> follows:
> 1) If the package does not have Type -64bit, then %lib expands to
> lib.
> 2) If the package does have Type -64bit, then the expansion of %lib
> depends on the architecture: it either expands to lib/ppc64 for
> powerpc, or lib/x86_64 for i386.
> 3) Possibly, the default value for LDFLAGS should become -L%p/%lib
> instead of -L%p/lib.
Perhaps, or have both -L%p/%lib -L%p/lib, see below for why.
> 4) Possibly, the default contents of %c should be expanded from "--
> prefix=%p" to "--prefix=%p --libdir='${prefix}/%lib' ".
I assume that any 64bit package will only install the libs. Is fink
planning to install 64bit binaries also? If so, where will it put
them? %p/bin/x86_64?
>
> So, a typical packaging which used this could include the following
> lines (explanation afterwards):
>
> Package: gmp%type_pkg[-64bit]
> Type: -64bit (binary)
> Depends: (%type_raw[-64bit] = -64bit) 64bit-cpu
> NoSetLDFLAGS: true
> SetLDFLAGS: -L%p/%lib
> ConfigureParams: --libdir='${prefix}/%lib'
> SplitOff: <<
> Package: %N-shlibs
> Files: %lib/libgmp.*.dylib
> Shlibs: <<
> %p/%lib/libgmp.3.dylib 8.0.0 %n (>= 4.2.1-1)
> <<
> <<
While this all makes sense, I think that if a fat build works and has
no issues either build or runtime, then a package should be allowed to
optionally build its libraries/programs "universal", while on tiger we
only have a few 64bit libraries in /, that is, I think, going to
change on leopard, if so it should be possible to build 64bit and
32bit fat libraries without messing with SDKs. Due to the nature of
the autotools, this is unlikely to work for every package, and those
packages that do not work should use the multilib dir, but when it
works fat, we may as well build fat, right?
Peter
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel
