Request for ideas on arch-specific musl-gcc specfile additions

Request for ideas on arch-specific musl-gcc specfile additions

[Rich Felker]

Right now, musl-gcc has problems on at least a few archs:

- powerpc: it does not setup the right secure-plt options for dynamic
  linking.

- mips: gcc's internals on mips expect the -EL and -EB options to work
  for selecting endianness, but they're not real options; they're
  created by the specfile

- any arch with 32/64-bit variants: if -m32 or -m64 was used building
  musl, it should get added to the specfile for musl-gcc.

I'm looking for a clean approach to fixing this. Certainly the
configure script could just generate one or more extra variables that
get stored in config.mak and substituted into the specfile, but I'd
rather avoid having essential logic like this in configure, as it
makes it difficult for anybody who wants to generate config.mak by
hand. If there are specific options always needed on a given arch, the
build process (even without configure being used) should automatically
add them to the specfile.

Any good proposals?

Rich

Re: Request for ideas on arch-specific musl-gcc specfile additions

[Zvi Gilboa]

On 04/14/2013 09:31 PM, Rich Felker wrote:
> Right now, musl-gcc has problems on at least a few archs:
>
> - powerpc: it does not setup the right secure-plt options for dynamic
>    linking.
>
> - mips: gcc's internals on mips expect the -EL and -EB options to work
>    for selecting endianness, but they're not real options; they're
>    created by the specfile
>
> - any arch with 32/64-bit variants: if -m32 or -m64 was used building
>    musl, it should get added to the specfile for musl-gcc.
>
> I'm looking for a clean approach to fixing this. Certainly the
> configure script could just generate one or more extra variables that
> get stored in config.mak and substituted into the specfile, but I'd
> rather avoid having essential logic like this in configure, as it
> makes it difficult for anybody who wants to generate config.mak by
> hand. If there are specific options always needed on a given arch, the
> build process (even without configure being used) should automatically
> add them to the specfile.

Two ideas come to mind:

1) similar to alltypes.h(.sh), have an arch-specific script generate the 
specs file, or at least that portion of the specs file that might 
contain arch-specific variants.

2) add arch-specific variables in the relevant places and set them from 
outside, possibly by executing musl-gcc.specs.sh from within an 
arch-specific shell script.  For instance:

*cpp_options:
$ARCH_SPECIFIC_CFLAGS -nostdinc -isystem $incdir %(old_cpp_options)


>
> Any good proposals?
>
> Rich

Re: Request for ideas on arch-specific musl-gcc specfile additions

[Rich Felker]

On Mon, Apr 15, 2013 at 12:31:34AM -0400, Zvi Gilboa wrote:
> 2) add arch-specific variables in the relevant places and set them
> from outside, possibly by executing musl-gcc.specs.sh from within an
> arch-specific shell script.  For instance:
> 
> *cpp_options:
> $ARCH_SPECIFIC_CFLAGS -nostdinc -isystem $incdir %(old_cpp_options)

Hmm, I had forgotten it was a shell script and not just a sed script
or something doing the replacements. So we could just put something
like:

$(case "$ARCH" in
mips*) echo "mips stuff here" ;;
powerpc*) echo "ppc stuff here" ;;
easc)

Does that work? Might have to add $ARCH to the args to the script, but
otherwise it seems ok.

Rich

Re: Request for ideas on arch-specific musl-gcc specfile additions

[Zvi Gilboa]

[-- Attachment #1: Type: text/plain, Size: 1376 bytes --]

On 04/15/2013 12:49 AM, Rich Felker wrote:
> On Mon, Apr 15, 2013 at 12:31:34AM -0400, Zvi Gilboa wrote:
>> 2) add arch-specific variables in the relevant places and set them
>> from outside, possibly by executing musl-gcc.specs.sh from within an
>> arch-specific shell script.  For instance:
>>
>> *cpp_options:
>> $ARCH_SPECIFIC_CFLAGS -nostdinc -isystem $incdir %(old_cpp_options)
> Hmm, I had forgotten it was a shell script and not just a sed script
> or something doing the replacements. So we could just put something
> like:
>
> $(case "$ARCH" in
> mips*) echo "mips stuff here" ;;
> powerpc*) echo "ppc stuff here" ;;
> easc)
>
> Does that work? Might have to add $ARCH to the args to the script, but
> otherwise it seems ok.
>
> Rich

I am not sure whether /echo/ will be the cleanest way, especially if 
customization is needed in multiple places.  Here is something that I 
just tested and seems to work:

*[musl-gcc.specs.sh*]
...
...
ARCH=$4*
*...
...
case "$ARCH" in
         x86_64*) CC1_ARCH_SPECIFIC_CFLAGS="x86_64-something-for-cc1" ;;
         powerpc*) CC1_ARCH_SPECIFIC_CFLAGS="powerpc-something-for-cc1" ;;
esac
...
...
*cc1:
*$CC1_ARCH_SPECIFIC_CFLAGS* %(cc1_cpu) -nostdinc -isystem $incdir


*[Makefile**]
*...
...
lib/musl-gcc.specs: tools/musl-gcc.specs.sh config.mak
         sh $< "$(includedir)" "$(libdir)" "$(LDSO_PATHNAME)" 
*"$(ARCH)"* > $@


[-- Attachment #2: Type: text/html, Size: 2185 bytes --]