On Fri, May 26, 2006, Bill Campbell wrote:

> [...]
> I think that the openpkg rc.openpkg run control should be setting
> LD_LIBRARY_PATH to use /lib64 and /usr/lib64.

Hmmm... I don't know, but this sounds like it can open a new can of
worms...

> [...]
> Building the Berkeley db package fails, unable to find things like
> db_create.  There are other linking issues that seemed to require that gcc
> be built with --enable-shared.

The BDB issue has to be a different type of problem. Building with
shared libraries is usually always just a workaround but not a solution
for the root of the problem.

> Some of the linking and configure problems seem to result from the libtool,
> automake, autoconf family searching the /lib and /usr/lib directories
> instead of /lib64 and /usr/lib64.  I did some tweaking using shtool to
> replace "/lib /usr/lib" with "/lib64 /usr/lib64", but this hardly seems
> like the Right Way(tm) to do this.

Yes, this cannot be the way to go. Next year some silly mixed-mode
friends create a /lib, /lib64 and a /lib128 and we start again from
scratch trying to fix all those tools.

> Looking at the gcc-4.0.3 gcc.spec file, it has multilib disabled for Intel
> 64 bit architectures.  Should this be disabled for amd64 as well?

This disabled multilib is just a cruel hack which was introduced to
circumvent some problems we had under Solaris/ix86. It will be gone once
GNU binutils are fixed. It should not be disabled in general.

> Can gcc be built to only produce 64-bit code, and is this a good idea?

I think it automatically supports mixed-mode platforms but it can
be forced to run in a particular mode (like 64-bit) by default AFAIK.

> If an OpenPKG instance is to have multiple libraries, this complicates
> things thoroughly such as %{l_prefix}/lib.  I would rather see multiple
> OpenPKG instances than mix them.
>
> Should gcc be called with the ``-m64'' option to find the correct library
> files?  If so, where's the best place to define this?

>From my point of view the way to go is that determine for a whole
OpenPKG instance whether to use 32 or 64 bit and then stick to this
forever (including e.g. to force GNU binutils to pick up lib64 stuff,
etc). Else it causes just lots of troubles when mixing those different
modes.
                                       Ralf S. Engelschall
                                       [EMAIL PROTECTED]
                                       www.engelschall.com

______________________________________________________________________
The OpenPKG Project                                    www.openpkg.org
Developer Communication List                   openpkg-dev@openpkg.org

Reply via email to