On Sun, Oct 30, 2011 at 08:08:41PM +0100, Peter Dyballa wrote:
>
> Am 30.10.2011 um 19:42 schrieb Jack Howarth:
>
> > Well, the warnings...
> >
> > ld: warning: in /opt/local/lib/libncurses.dylib, file was built for
> > unsupported file format which is
> > not the architecture being linked (i386)
> > ld: warning: in /opt/local/lib/libbz2.dylib, file was built for unsupported
> > file format which is not the
> > architecture being linked (i386)
> > ld: warning: in /opt/local/lib/libotf.dylib, file was built for unsupported
> > file format which is not the
> > architecture being linked (i386)
> >
> > alone show that you are trying to build x86_64 with i386 fink which will be
> > extremely problematic since we
> > don't build fat shared libraries for things like ncurses.
>
> That's OK with me. If I need 64-bit binaries for daily use I'd use Mac OS X's
> GCC 4.0 or 4.2.
>
> > Also I am still baffled as to how you are linking
> > in from /opt/local/lib.
>
> Because I wanted to build the X11 variant of GNU Emacs with a more up-to-date
> compiler in 64 bit. (In 32-bit it works quite OK.) It's a try to see whether
> such a product works or has bugs.
>
> > Frankly if you want to build x86_64, I would create a new x86_64 fink
> > bootstrap installed at
> > /sw_x86_64.
>
> Why do the 32-bit GCC executables advertise the ability to support 64-bit
> binaries and then fail? Why is the installation so incomplete? With the
> installed GCC 4.6 I am not even able to cross-compile for my native Sandy
> Bridge (or any other Core2) hardware.
I am still unconvinced that your real problem isn't the fact that you are
using i386 fink to compile a program
which requires non-system x86_64 shared libraries which i386 fink won't
provide. FYI, I have considered abandoning the
multilib build for the gcc4x packages but the FSF gcc compiler doesn't provide
a clear error message in that case when
-m64 is passed to gcc-4 in i386 fink or -m32 is passed to gcc-4 in x86_64 fink.
Also note that you will have similar issues
under MacPorts since only a subset of their packages are built as fat binaries.
ps The fact that you end up linking in from /opt/local strongly suggests that
the emacs configure is looking in /opt/local
for includes and shared libs which effectively causes fink to be mixed with
MacPorts which simply won't work.
>
> > Also I would prune down your .cshrc/.bashrc to stop dragging in includes
> > and/or libs from /opt/local.
>
> This dragging happens with environment variables I set purposely in GNU Emacs
> when I start a configure run in its compile-mode. The shell environment is
> kept quite small and clean.
>
> --
> Greetings
>
> Pete
>
> Theory and practice are the same, in theory, but, in practice, they are
> different.
------------------------------------------------------------------------------
Get your Android app more play: Bring it to the BlackBerry PlayBook
in minutes. BlackBerry App World™ now supports Android™ Apps
for the BlackBerry® PlayBook™. Discover just how easy and simple
it is! http://p.sf.net/sfu/android-dev2dev
_______________________________________________
Fink-users mailing list
[email protected]
List archive:
http://news.gmane.org/gmane.os.macosx.fink.user
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-users
