Re: [Fink-devel] 64bit libraries and a new percent expansion
Heh, nevermind, found the 64bit-cpu package... as mentioned in other reply! *hides* - 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
Re: [Fink-devel] 64bit libraries and a new percent expansion
>While you are adding this to fink, would it be possible to use some
> MacOS X system call to detect the presence of 64-bit support on the
> processor? I have thought it would be handy to have such a flag as
> available for checking in info scripts for such cases as a
> gcc42-64-bit package (which would be a native 64-bit build of the gcc
> compiler itself).
Hi all,
One thing I've found works is to compile a 64-bit dummy binary at
patch-time or configure-time.
% echo "int main(int, char*[]) { return 0; }" > test64.cc
% g++ -m64 test64.cc -o test64
% ./test64 > /dev/null 2>&1
the execution will fail if 64-bit is unsupported. Does this suffice?
I was able to test an early draft of your gcc4 packaging that way (back
when we wanted to conditionally --disable-multilib).
Maybe even useful as a pseudo-package for 64b dependency tracking?
David Fang
Computer Systems Laboratory
Electrical & Computer Engineering
Cornell University
http://www.csl.cornell.edu/~fang/
-- (2400 baud? Netscape 3.0?? lynx??? No problem!)
-
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
Re: [Fink-devel] 64bit libraries and a new percent expansion
That's already there (added last summer): a virtual package called "64bit-cpu" which you may add to Depends or BuildDepends where appropriate. -- Dave On Nov 22, 2006, at 7:06 AM, Jack Howarth wrote: > David, >While you are adding this to fink, would it be possible > to use some MacOS X system call to detect the presence of > 64-bit support on the processor? I have thought it would > be handy to have such a flag as available for checking > in info scripts for such cases as a gcc42-64-bit package > (which would be a native 64-bit build of the gcc compiler > itself). >Jack > > -- > --- > 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 - 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
Re: [Fink-devel] 64bit libraries and a new percent expansion
David, While you are adding this to fink, would it be possible to use some MacOS X system call to detect the presence of 64-bit support on the processor? I have thought it would be handy to have such a flag as available for checking in info scripts for such cases as a gcc42-64-bit package (which would be a native 64-bit build of the gcc compiler itself). Jack - 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
Re: [Fink-devel] 64bit libraries and a new percent expansion
On 11/19/06, Peter O'Gorman <[EMAIL PROTECTED]> wrote:
>
> On Nov 19, 2006, at 1:43 AM, David R. Morrison wrote:
> > 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?
openmcl-64bit currently installs a 64bit (ppc only) binary in %p/bin.
I haven't spent a lot of time thinking about it, but I don't
understand why 64bit binaries would need to be placed in a separate
directory.
Lars
--
Lars Rosengreen
http://www.phylopy.org/~lars
-
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
Re: [Fink-devel] 64bit libraries and a new percent expansion
On 11/18/06, David R. Morrison <[EMAIL PROTECTED]> wrote: > 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.) openmcl-64 bit doesn't actually install any shared libraries in %p/lib64/%n. It installs its lisp image and some lisp libraries there. I can easily move those items to another location without breaking anything. It's a bit of an oddity in that it is ppc64 only, and not autotool'd. Lars -- Lars Rosengreen http://www.phylopy.org/~lars - 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
Re: [Fink-devel] 64bit libraries and a new percent expansion
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
Re: [Fink-devel] 64bit libraries and a new percent expansion
A quick followup thought: if we add --libdir='${prefix}/%lib' to the %
c defaults, then we should introduce a NoSetLibdir command to disable
that when necessary.
-- Dave
On Nov 18, 2006, at 8: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.
> 4) Possibly, the default contents of %c should be expanded from "--
> prefix=%p" to "--prefix=%p --libdir='${prefix}/%lib' ".
>
> 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)
> <<
> <<
>
> This fragment of an .info file would be used to build both the gmp
> and gmp-64bit packages; would build splitoffs for each; the 64bit
> variant depends on the 64bit-cpu virtual package as it should; the
> LDFLAGS is reset to the correct location (unless we make that part
> of the default); the configure script is fed the correct library
> directory (unless we make that part of the default); the shared
> library files are correctly moved into the -shlibs splitoff, and
> they are correctly documented in the Shlibs field.
>
> Comments?
>
> -- Dave
>
-
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
[Fink-devel] 64bit libraries and a new percent expansion
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.
4) Possibly, the default contents of %c should be expanded from "--
prefix=%p" to "--prefix=%p --libdir='${prefix}/%lib' ".
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)
<<
<<
This fragment of an .info file would be used to build both the gmp
and gmp-64bit packages; would build splitoffs for each; the 64bit
variant depends on the 64bit-cpu virtual package as it should; the
LDFLAGS is reset to the correct location (unless we make that part of
the default); the configure script is fed the correct library
directory (unless we make that part of the default); the shared
library files are correctly moved into the -shlibs splitoff, and they
are correctly documented in the Shlibs field.
Comments?
-- Dave
-
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
