On Jan 13, 2007, at 10:57 AM, Jean-François Mertens wrote:
>
> As to the general problem, on the one hand I see no major reason
> not to allow
> %lib w/o the Type field; on the other hand I prefer general mechanisms
> _ like allowing conditionals _ to very specialised ones ...
>
The %lib mecha
On 13 Jan 2007, at 16:57, Jean-François Mertens wrote:
> 1) everything in the ppc64 or x86_64 subdirectory of /sw/lib/gcc4.2/
> lib should go in the -shlibs splitoff.
"everything" = *.*.dylib , of course..
JF
-
Take Surveys
On 13 Jan 2007, at 17:30, Jack Howarth wrote:
> JF
> The fat libgcc files are as expected...
Of course. Was just correcting an inaccuracy...
> On Sat, Jan 13, 2007 at 04:00:47PM +0100, Jean-François Mertens wrote:
>>
>> On 13 Jan 2007, at 14:59, Jack Howarth wrote:
>>
>>> Dave,
>>> The anal
On 13 Jan 2007, at 14:59, Jack Howarth wrote:
>We really do want to move the libraries currently in
> /sw/lib/gcc4.2/lib/ppc64 from the gcc42 package to the
> gcc42-shlibs package. Otherwise anything built with -m64
> will break when we need to create a gcc43 package later
> since the gcc4X p
On 13 Jan 2007, at 14:59, Jack Howarth wrote:
> Dave,
>The analysis of gcc42 is incorrect. There are no fat binaries
> created but rather an explicit 64-bit subdirectory.
A small correction: at least I am getting 3 fat libraries /sw/lib/
gcc4.2/lib/libgcc_s.*.dylib
Jean-Francois
-
Dave,
One other note. While both Apple's and FSF's gcc both
have ppc64 and x86_64 subdirectories, I would note that
Apple's compiler uses lipo to create fat shared libs but
FSF gcc doesn't. One reason for this may be that the FSF
gcc is intended to be used with MacOS X as far back as
10.3.9. In
Dave,
The analysis of gcc42 is incorrect. There are no fat binaries
created but rather an explicit 64-bit subdirectory. So we have
for example...
/sw/lib/gcc4.2/lib/libgfortran.2.0.0.dylib
currently in the gcc42-shlibs package and...
/sw/lib/gcc4.2/lib/ppc64/libgfortran.2.dylib
in the gcc42
On Jan 12, 2007, at 8:20 PM, Alexander Hansen wrote:
> On 1/12/07, Jack Howarth <[EMAIL PROTECTED]> wrote:
>>I'm still unclear how we can leverage the architecture Shlibs
>> field for the multilib build of the gcc42 package. The standard
>> multilib installation for gcc is to have the shared
On Jan 12, 2007, at 6:53 PM, Jack Howarth wrote:
>I'm still unclear how we can leverage the architecture Shlibs
> field for the multilib build of the gcc42 package. The standard
> multilib installation for gcc is to have the shared libs installed
> for the default architecture (32-bit for Dar
On 1/12/07, Jack Howarth <[EMAIL PROTECTED]> wrote:
>I'm still unclear how we can leverage the architecture Shlibs
> field for the multilib build of the gcc42 package. The standard
> multilib installation for gcc is to have the shared libs installed
> for the default architecture (32-bit for Da
I'm still unclear how we can leverage the architecture Shlibs
field for the multilib build of the gcc42 package. The standard
multilib installation for gcc is to have the shared libs installed
for the default architecture (32-bit for Darwin) in lib/gcc4.2/lib
and the secondary multilib (64-bit)
On 12 Jan 2007, at 06:12, David R. Morrison wrote:
> ... in the Packaging Manual, in the
> Shared Libraries section. There, we document the new, optional, 4th
> item in a Shlibs entry, and indicate that its value can be "32",
> "64", or "32-64". The last option refers to libraries which were
>
I wanted to discuss how "multilib" builds should be handled in Fink.
To the best of my knowledge, we don't have any of these yet, but I
understand that one is about to be added.
This is a very small hint about this in the Packaging Manual, in the
Shared Libraries section. There, we documen
13 matches
Mail list logo
