Co-existing i386 and x86_64 libraries?

Co-existing i386 and x86_64 libraries?

[Oliver Schneider]

Hi,

short of setting different prefixes for each respective build, what
could I do to have two coexisting musl-libc libraries, one for -m64 and
one for -m32 builds on IA-32?

The compiler (gcc in my case) supports the targets and the following
does the job on a 64-bit host:

./configure --enable-debug --target=i386 CFLAGS=-m32 CC="ccache gcc"

However, I have yet to find a solution to having both builds live
peacefully together under the same "prefix" and the specs file used by
the GCC wrapper choosing the proper architecture.

Any ideas how to accomplish this?

Looking at the Makefile the way it stands, I reckon this is virtually
impossible. There are hardcoded library names used after including
config.mak, so overriding something like that inside config.mak is hopeless.

Thanks,

// Oliver

PS: on another note, the Makefile appears to use GNU-make-isms, wouldn't
it make sense to name it GNUmakefile in order to avoid it being picked
up by other make flavors? Or am I missing something here?

Re: Co-existing i386 and x86_64 libraries?

[Rich Felker]

On Tue, Apr 29, 2014 at 10:20:05PM +0000, Oliver Schneider wrote:
> Hi,
> 
> short of setting different prefixes for each respective build, what
> could I do to have two coexisting musl-libc libraries, one for -m64 and
> one for -m32 builds on IA-32?
> 
> The compiler (gcc in my case) supports the targets and the following
> does the job on a 64-bit host:
> 
> ../configure --enable-debug --target=i386 CFLAGS=-m32 CC="ccache gcc"

As a general practice it's probably better to put the -m32 as part of
$CC, but this should work too for musl.

> However, I have yet to find a solution to having both builds live
> peacefully together under the same "prefix" and the specs file used by
> the GCC wrapper choosing the proper architecture.

You need separate libdirs for each arch. This is fundamental; it's not
specific to musl.

> Any ideas how to accomplish this?
> 
> Looking at the Makefile the way it stands, I reckon this is virtually
> impossible. There are hardcoded library names used after including
> config.mak, so overriding something like that inside config.mak is hopeless.

Renaming the libraries is definitely not a viable solution. The names
are all fixed because they have to be.

> Thanks,
> 
> // Oliver
> 
> PS: on another note, the Makefile appears to use GNU-make-isms, wouldn't
> it make sense to name it GNUmakefile in order to avoid it being picked
> up by other make flavors? Or am I missing something here?

We have some ppl involved with the project who are allergic to seeing
the letters G, N, and U together anyhere...

Rich

Re: Co-existing i386 and x86_64 libraries?

[Oliver Schneider]

Hi Rich, all,

On 2014-04-30 03:00, Rich Felker wrote:
> You need separate libdirs for each arch. This is fundamental; it's not
> specific to musl.
But the include dirs can be shared, or are the headers being "primed"
somehow, during the build?

> Renaming the libraries is definitely not a viable solution. The names
> are all fixed because they have to be.
Yeah, I noticed after sending my message ;)

> We have some ppl involved with the project who are allergic to seeing
> the letters G, N, and U together anyhere...
Alright then.

// Oliver

Re: Co-existing i386 and x86_64 libraries?

[Rich Felker]

On Fri, May 02, 2014 at 10:47:10AM +0000, Oliver Schneider wrote:
> Hi Rich, all,
> 
> On 2014-04-30 03:00, Rich Felker wrote:
> > You need separate libdirs for each arch. This is fundamental; it's not
> > specific to musl.
> But the include dirs can be shared, or are the headers being "primed"
> somehow, during the build?

I was talking about things needed for runtime. For development you
even need separate bin dirs (think pkg-conf, getconf, etc.) for the
configure scripts to work right. At present musl's headers can be
shared between archs except for the bits subdir (so you can make a
custom install where bits isn't in the shared include dir, and instead
add it to gcc's default include path) but this isn't a permanent
guarantee that it will work that way. You're best off having all
development-related files be separate per-arch.

Rich