Re: [Fink-devel] [Fink-users] EMBOSS: dependency problems on X86_64

2010-08-25 Thread Daniel Macks
On Tue, 24 Aug 2010 21:07:03 -0400, Alexander Hansen wrote: On 8/24/10 8:34 PM, Hanspeter Niederstrasser wrote: On 8/24/10 6:46 PM, Scott R. Santos wrote: 2) I now get the following error when I try to update EMBOSS on X86_64 systems (didn't happen before the new plplot was

Re: [Fink-devel] [Fink-users] EMBOSS: dependency problems on X86_64

2010-08-25 Thread Alexander Hansen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/25/10 5:29 AM, Daniel Macks wrote: On Tue, 24 Aug 2010 21:07:03 -0400, Alexander Hansen wrote: On 8/24/10 8:34 PM, Hanspeter Niederstrasser wrote: On 8/24/10 6:46 PM, Scott R. Santos wrote: 2) I now get the following error when

Re: [Fink-devel] [Fink-users] EMBOSS: dependency problems on X86_64

2010-08-25 Thread Jean-François Mertens
On 25 Aug 2010, at 03:07, Alexander Hansen wrote: Until such time as wxmac-2.9.1 makes it into Fink, unless somebody has another idea, I think we need to pull plplot, emboss ... from the 10.6/ x86_64 tree. and similarly for 10.5/x86_64 .. But pls don't without making a plplot-gtk

Re: [Fink-devel] [Fink-users] EMBOSS: dependency problems on X86_64

2010-08-25 Thread Hanspeter Niederstrasser
Another idea wins. That sounds good to me. (Not that I would totally hate having an updated wxmac so that wxmaxima could enter the x86_64 world) For the recored wxWidgets-2.9.1 with the --with-osx_cocoa flag built OK for me as 64bit outside of Fink (but using Fink64 supplied libraries). I

[Fink-devel] multiarch libraries in gcc44/45 on i386

2010-08-25 Thread Alexander Hansen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm not sure if this is intentional, but I get the following from gcc44-4.4.4-1000 (similarly for gcc45-4.5.0-1000) on 10.6/i386 and 10.5/i386 $ dpkg -L gcc44-shlibs | grep dylib | xargs file /sw32/lib/gcc4.4/lib/gcj-4.4.4-10/libjvm.dylib:

Re: [Fink-devel] multiarch libraries in gcc44/45 on i386

2010-08-25 Thread Jack Howarth
Alexander, Apple has always built libgcc in that manner. It is the one exception in the multilib build where a separate subdirectory isn't used. The new versioned libgcc_ext stubs (which provide all the additional symbols from FSF libgcc which aren't in libgcc_s.10.4/10.5) is built the same