[Fink-devel] 64bit shared libraries

[David R. M. <dr...@fi...>]

Dear fink developers,

I realized today that there is another wrinkle in the discussions  
we've been having about 64bit libraries.  I've gone ahead an  
implemented the policy part of the previous discussion --  
architecture-dependent storage locations for 64bit libraries -- and  
we now have three packages for 64bit and they all store things in the  
correct locations.

However, I've realized that we will need to modify our Shlibs policy  
to properly handle the case of 64bit libraries.  The issue is this:  
if we are going to build some libraries 'fat', which can be linked to  
by other 64bit libraries, then the Shlibs field will need a way to  
keep track of which libraries have 64bit components and which ones do  
not.  I see two possible strategies:

Strategy1: Add a Shlibs64 field in addition to the Shlibs field.  A  
64bit-only lib would declare Shlibs64; a 32bit-only lib would declare  
Shlibs.  Any fat libs would need two entries.

Strategy2: Add an optional fifth field to each Shlibs entry, with  
possible values "32", "64", or "fat".  (If absent it would default to  
32.)  This would indicate which kinds of libs would be present in the  
file.

In either case, we'll need some kind of percent expansion to treat  
the case of a single .info file building things in both 32 and 64bit  
mode.  In the first case, we'd want Shlibs%64 where %64 is empty in  
the 32 bit case.  (But this is something we've never had before: the  
% modifying the name of the field, not the contents of the field.  Is  
it feasible?)  In the second case, we'd want a percent expansion  
which resolved to either 32 or 64 (or possibly again, empty or 64).

We could have %type_bit[-64bit] which strips off leading '-' if  
present, trailing 'bit' if present, and chucks out the rest -- this  
would work for both.  But I don't like that too well, and am very  
open to suggestions.

   -- Dave