Compiling on 64 bit SuSE (Was Re: List OK?)

[Robert Heller]

  "Maf. King" <maf at chilwell.net>,
  In a message on Mon, 5 Sep 2005 23:47:27 +0100, wrote :

MK> On Monday 05 Sep 2005 22:47, Des Dougan wrote:
MK> > On Mon, 2005-09-05 at 17:40 -0400, Robert Heller wrote:
MK> > >   Des Dougan <des at douganconsulting.com>,
MK> > >   In a message on Mon, 05 Sep 2005 14:10:53 -0700, wrote :
MK> > >
MK> > > DD> On Mon, 2005-09-05 at 12:44 -0700, Des Dougan wrote:
MK> > > DD> > On Mon, 2005-09-05 at 14:08 -0400, Derek Atkins wrote:
MK> > > DD> > > Quoting Des Dougan <des at DouganConsulting.com>:
MK> > > DD> > >
MK> > > DD> > > > The make step has failed, though - something in make is looking
MK> > > at a 32 DD> > > > bit library instead of the 64 bit:
MK> > > DD> > >
MK> > > DD> > > That's not surprising -- GnuCash 1.8 was never ported to 64-bit
MK> > > platforms... DD> > >
MK> > > DD> > > > make[4]: Entering directory
MK> > > DD> > > >
MK> > > `/home/des/Downloads/tarballs/gnucash/gnucash-1.8.11/src/gnc-module' DD>
MK> > > > > > /bin/sh ../../libtool --mode=link gcc -I../../src/core-utils DD> >
MK> > > > > -I/opt/gnome/include/glib-1.2 -I/opt/gnome/lib64/glib/include -I DD>
MK> > > > > > /usr/local/include/g-wrap  -g -O2 -Wall -Wunused    -o DD> > > >
MK> > > libgncmodule.la -rpath /usr/lib64 -module gnc-module.lo DD> > > >
MK> > > ../core-utils/libcore-utils.la -L/usr/local/lib -lgwrap-wct DD> > > >
MK> > > -lgwrap-glib -L/opt/gnome/lib64 -lglib -lltdl -lpopt -lm  -lm DD> > > >
MK> > > gcc -shared  .libs/gnc-module.o  -Wl,--rpath
MK> > > DD> > > >
MK> > > -Wl,/home/des/Downloads/tarballs/gnucash/gnucash/src/core-utils/.libs DD>
MK> > > > > > -Wl,--rpath -Wl,/usr/local/lib -Wl,--rpath -Wl,/opt/gnome/lib64 DD>
MK> > > > > > -Wl,--rpath -Wl,/usr/lib64 -Wl,--rpath -Wl,/usr/local/lib
MK> > > -Wl,--rpath DD> > > > -Wl,/opt/gnome/lib64  -L/usr/lib64
MK> > > -L/opt/gnome/lib64
MK> > > DD> > > > ../core-utils/.libs/libcore-utils.so -L/usr/local/lib
MK> > > DD> > > > /usr/local/lib/libgwrap-wct.so /usr/local/lib/libgwrap-glib.so
MK> > > DD> > > > /opt/gnome/lib64/libglib.so /usr/lib/libltdl.so -lpopt -lm
MK> > > DD> > > > -Wl,-soname -Wl,libgncmodule.so.0 -o
MK> > > .libs/libgncmodule.so.0.0.0 DD> > > > /usr/lib/libltdl.so: could not read
MK> > > symbols: File in wrong format DD> > > >
MK> > > DD> > > > I've confirmed that there is a libltdl.so in the /usr/lib64
MK> > > directory, DD> > > > and I've gone through the configure script and the
MK> > > make man pages to DD> > > > check how to inform make that it's a 64 bit
MK> > > compile, but can find DD> > > > nothing that help me.
MK> > > DD> > >
MK> > > DD> > > Sorry, don't know what to tell you...
MK> > > DD> > >
MK> > > DD> > > > Am I missing something fundamental at the configure stage? The
MK> > > script DD> > > > I'm using is as follows:
MK> > > DD> > > >
MK> > > DD> > > > #!/bin/sh
MK> > > DD> > > > CC=gcc
MK> > > DD> > > > CFLAGS=-O2
MK> > > DD> > > > PATH="$PATH:/opt/gnome/bin"
MK> > > DD> > > > (cd gnucash
MK> > > DD> > > > rm -rf config.cache
MK> > > DD> > > > ./configure --prefix=/opt/gnome --libdir=/usr/lib64
MK> > > --enable-gui DD> > > > --enable-ofx \
MK> > > DD> > > >        --build=x86_64-linux-gnu --disable-error-on-warning
MK> > > DD> > > > )
MK> > > DD> > > > # end of script
MK> > > DD> > > >
MK> > > DD> > > > Thanks,
MK> > > DD> > > >
MK> > > DD> > > > Des
MK> > > DD> > >
MK> > > DD> > > Honestly, I don't know.  But I don't think 1.8 will build on
MK> > > 64-bit DD> > > platforms. I know a bunch of changes have gone into CVS to
MK> > > get gnucash DD> > > working on 64-bit
MK> > > DD> > > platforms, but I'm fairly certain those didn't go into 1.8...  
MK> > > So it's quite DD> > > likely you're working on a futile effort in any
MK> > > event.
MK> > > DD> >
MK> > > DD> > Well, that is a major issue for me - the shipped gnucash on SuSE
MK> > > 9.3 has DD> > a bug with importing OFX files (which I've reported to
MK> > > SuSE) and which DD> > is why I built 1.8.11 on my previous box...
MK> > > DD> >
MK> > > DD> > Thanks for all your help (and I see that my last email made it to
MK> > > the DD> > list...).
MK> > > DD> >
MK> > > DD> > Regards,
MK> > > DD> >
MK> > > DD> > Des
MK> > > DD>
MK> > > DD>
MK> > > DD> Well, I decided to press on. libltdl.so is a symbolic link to
MK> > > DD> libltdl.so.1 in /usr/lib, so I created a new symbolic link to
MK> > > DD> the /usr/lib64 directory. This got me further and carrying out the
MK> > > same
MK> > >
MK> > > You *really* don't want to do this!  The libltdl.so.1 in /usr/lib is
MK> > > most likely the *32* bit library.  The libraries in /usr/lib64 are the
MK> > > 64 bit libraries.  It is important to understand that the '64 bit' ix86
MK> > > processors (eg AMD64, IS64), also run in 32-bit mode.  BUT a given
MK> > > process is either in 32 or 64 bit mode.  You can switch modes within a
MK> > > given process and thus you cannot link a 64-bit program with 32-bit
MK> > > libraries.  You are probably missing the 64-bit version of libltdl.so OR
MK> > > somehow the install of libltdl placed the 64 bit library in with the
MK> > > 32-bit libraries.
MK> >
MK> > Hi Robert,
MK> >
MK> > I think you've misunderstood me - there is a libltdl.so.1 in
MK> > both /usr/lib and /usr/lib64, but the symbolic link
MK> > at /usr/lib/libltdl.so was pointing to the 32 bit version in /usr/lib. I
MK> > changed it to point to the 64 bit version in /usr/lib64, as the make was
MK> > using the 32 bit version. Changing the symbolic link to point
MK> > to /usr/lib64 got make past the problem.
MK> >
MK> > Or am I missing something (which may be entirely possible - I'm feeling
MK> > my way in the dark here).

The symlink of libltdl.so in /usr/lib/ should be pointing to the 32-bit
version, never the 64-bit version. All of the libraries (including the
.so symlinks) under /usr/lib/ are 32-bit.  You should not have links in
/usr/lib/ to libraries in /usr/lib64, since this will break any 32-bit
applications you may run.  Your link step for the 64-bit application
*should not* be linking to anything in /usr/lib/, it should be linking
with stuff in /usr/lib64/.  The fact that the Makefile is looking in
/usr/lib/ at all suggests that something else is wrong --
./configure(.in) might be broken (probably is).  I noticed that you are
also looking in /usr/local/lib -- I wonder if that is also a mistake
and maybe you should be looking in /usr/local/lib64/ and maybe the
install targets on some local dependencies are also broken.  Or maybe
you need to 'force' things with the use of
--with-<mumble>=/usr/lib64/<mumble> (or
--with-<mumble>=/usr/local/lib64/) options to ./configure, or something
like that.  Or --libdir=/usr/lib64 (or --libdir=/usr/local/lib64) might
be needed.

It is also possible that you have a *wrong* -devel package installed
somehow as well.  You *should not* have any
<libmumble>-devel-<version>.i[3456]86.rpms installed.  Only
<mumble>-devel-<version>.x86_64.rpms.  You will have
<libmumble>-<version>.i[3456]86.rpms AND
<libmumble>-<version>.x86_64.rpms installed.  The
<libmumble>-<version>.i[3456]86.rpms put runtime stuff in /usr/lib/...
and the <libmumble>-<version>.x86_64.rpms put runtime stuff in
/usr/lib64/ and the <mumble>-devel-<version>.x86_64.rpms put compile
and linktime stuff in /usr/include/ and /usr/lib64/ AND might also put
various sorts of configure stuff in /usr/bin or someplace (someplace
./configure will look). These files/programs/scripts will have
/usr/lib64/, for the *64-bit* libraries as the linker/library options
needed.  The <libmumble>-<version>.i[3456]86.rpms will have /usr/lib/
as the linker/library options, for the *32-bit* libraries, which for a
64-bit build is wrong.  Somehow the configure script is picking up a
-L/usr/lib, and it *should not be*.

Things are 'interesting' on the x86_64 and ia64 machines.  These
processors can run as 32 or 64 bit processors, on a process-by-process
basis (processor mode is just some additional process context
information handled by the kernel).  Suse (like RedHat/WBL) seem to be
providing 32-bit compatibility, by installing 32-bit libraries in the
'normal' places (/usr/lib/) for the 'convenience' of applications built
on 32-bit systems and placing the 64-bit libraries under /usr/lib64/. 
The 64-bit applications are built in a way (or at least the ld.so tool
is built this way) to look in /usr/lib64/ instead of /usr/lib/ for
shared libraries at run time.

MK> >
MK> > Thanks,
MK> >
MK> > Des
MK> 
MK> Hi Des,
MK> 
MK> Just to add a couple of cents - I'm in a similar position at the moment, 
MK> trying to get a CAD-viewer app to build on my first x86_64 box (SuSE 9.3), 
MK> and I feel that you might get more mileage out of trying to build GC as a 32 
MK> bit app.
MK> 
MK> It is what I intend to try next (when I get time)- force everything "down" to 
MK> 32 bit, which seems not to be the intended SuSE way, as the /*/lib64 
MK> directories seem to be preferred....

This is actually typically on a 64-bit box with the 64-bit O/S installed --
WBL 3.0 / RHEL 3.0 is the same.  If the app fails to build properly as a
64-bit application, you might need use a 32-bit box to build it as a
32-bit application.

I don't think it is 'easy' to build 32-bit applications on a 64-bit,
unless you do it with something like a cross-build set up.  The 'easy'
solution would be to install the 32-bit version of the O/S (Suse 9.3?)
on a 'vanila' 32-bit system (eg a basic P4 system) and build it there
and copy the binary over to the 64-bit machine (eg create a .i386.rpm
and install this).

MK> 
MK> But I too am working along in the dark on this.
MK> 
MK> Good Luck,
MK> Maf.
MK>  
MK> 
MK> -----BEGIN PGP SIGNATURE-----
MK> Version: GnuPG v1.4.0 (GNU/Linux)
MK> 
MK> iD8DBQBDHMsD5ZHo4Q3nxUIRAtOoAKCM8NyULhypkojCd6zgmSS1SULyrgCfVplN
MK> 2wRWQjK1Bd9HxUFS+817SJA=
MK> =9JaE
MK> -----END PGP SIGNATURE-----
MK> 
MK> MIME-Version: 1.0
MK> 
MK> _______________________________________________
MK> gnucash-user mailing list
MK> gnucash-user at gnucash.org
MK> https://lists.gnucash.org/mailman/listinfo/gnucash-user
MK> 
MK>                                                                  

                                     \/
Robert Heller                        ||InterNet:   heller at cs.umass.edu
http://vis-www.cs.umass.edu/~heller  ||            heller at deepsoft.com
http://www.deepsoft.com              /\FidoNet:    1:321/153