Mail archive

Re: [alpine-devel] Bunch of questions about Alpine's gcc package

From: Natanael Copa <>
Date: Sun, 19 May 2013 13:08:29 +0200

On Fri, 17 May 2013 13:07:20 -0400
Dubiousjim <> wrote:

I'll try answer some of the more questions you had...

> One thing I notice is that Alpine configures uClibc without largefile
> support:
> $ fgrep LARGEFILE main/libc0.9.32/uclibcconfig.x86*
> main/libc0.9.32/uclibcconfig.x86:# UCLIBC_HAS_FOPEN_LARGEFILE_MODE
> is not set
> main/libc0.9.32/uclibcconfig.x86_64:#


Answer Y to enable a uClibc-specific extension to allow passingan
additional 'F' flag in the mode string for fopen() to specify that the
file should be open()ed with the O_LARGEFILE flag set.

Most people will answer N.

> Hence I did not select the BR2_TOOLCHAIN_BUILDROOT_LARGEFILE option in
> buildroot's config, and so buildroot configures its gcc with
> --disable-largefile. However, we don't specify that in Alpine's gcc
> APKBUILD. Should we do so, given that we don't have largefile support
> enabled in uClibc?

We have large file support.

> Another thing I notice is that buildroot doesn't set the
> --with-dynamic-linker flags, and as a result the ldd output of
> binaries it generates look a bit different from those generated by
> Alpine's native gcc. This may be connected to the issue I mentioned
> at the beginning, about needing to make symlinks for some library
> files on Alpine, to be able to execute the binaries generated by the
> cross-compiler.

Yes. Also this is relevant to get the Alpine Linux uclibc

        # set abi version and remove unsupported warnings c flag
        sed -i -e "s/^ABI_VERSION.*/ABI_VERSION := $_abiver/" \
                -e "s/-Wold-style-declaration//g" \

You need the gcc-4.7-dynamic-linker.patch and you need to set the
--with-dynamic-linker=0.9.32 which is our current ABI version.

> These are options that Alpine uses when configuring gcc that I wasn't
> able to find documentation on (for instance, at
> Might some of these
> options now be obsolete? Or could anyone offer any explanation of
> these, and suggestions about whether I should also apply them to the
> cross-compiler. (I will continue to research these, as well.)
> --disable-altivec # from what I could see, gcc's
> -maltivec option is only relevant for RS/6000 and PowerPC

I think its unrelevant yes.

> --disable-build-with-cxx

I think this was to disable the c++ version of gcc. I think it broke
the gcc plugins for our grsecurity kernel. I am not sure if grsecurity
has resolved those issues or what the status is there.

> --disable-libstdcxx-pch

not sure.

> --enable-esp

to enable the genetoo hardened patches.

> --without-system-libunwind
> Alpine used the option --enable-__cxa_atexit but buildroot, at least
> with the configuration options I selected, uses
> --disable-__cxa_atexit. Any insight into this conflict?

I don't remember. Looks like it was introduced with 7302771c, the
initial gcc commit?

> Alpine uses all of these options (which I could find documentation
> about) but buildroot currently does not:
> --disable-werror

This is to disable the exit with error when hit a gcc warning.

> --disable-checking

dont rememember.

> --disable-fixed-point

I don't think this is relevant to us and could probably be removed.
    Enable (or disable) support for C fixed-point arithmetic. This
    option is enabled by default for some targets (such as MIPS) which
    have hardware-support for fixed-point operations. On other targets,
    you may enable this option manually.

> --enable-cld
I think this was the reason:

> --with-system-zlib

link against the system libz rather than use the embedded version in
gcc. It makes our gcc slightly smaller but makes it depend on zlib.

> Alpine uses --enable-cloog-backend. I couldn't find info specifically
> about this option, but I did find info about the options
> ...
> buildroot currently doesn't use any of these options.
> buildroot currently uses these options (which I could find
> documentation about) but Alpine's gcc does not:
> --disable-libquadmath
> --disable-libgomp
> --disable-decimal-float
> Again, any insight into these conflicts? Should I make buildroot
> conform to Alpine in these respects?

I'm not sure, but remeber hat buildroot targets many more targets than
> I know there's a lot of info/questions here. I'd be glad for any
> partial answers, too.

I could mention that when we did the NPTL bootstrapping we used
crosstool-ng rather than buildroot. Main reason was that buildroot does
(did?) not provide us with a native gcc.


Received on Sun May 19 2013 - 13:08:29 UTC