Date: Sun, 19 May 2013 13:08:29 +0200
From: Natanael Copa <ncopa@alpinelinux.org>
To: Dubiousjim <lists+alpine-devel@jimpryor.net>
Cc: Alpine <alpine-devel@lists.alpinelinux.org>
Subject: Re: [alpine-devel] Bunch of questions about Alpine's gcc package
Message-ID: <20130519130829.6bf07235@ncopa-laptop.res.nor.wtbts.net>
In-Reply-To: <1368810440.11585.140661232362869.109C2D3D@webmail.messagingengine.com>
References: <1368810440.11585.140661232362869.109C2D3D@webmail.messagingengine.com>
Precedence: list
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Fri, 17 May 2013 13:07:20 -0400
Dubiousjim <lists+alpine-devel@jimpryor.net> 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:#
>     UCLIBC_HAS_FOPEN_LARGEFILE_MODE is not set

UCLIBC_HAS_FOPEN_LARGEFILE_MODE:

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.
UCLIBC_HAS_LFS=y

 
> 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" \
                Rules.mak

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
> http://gcc.gnu.org/install/configure.html). 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-fixed-point
--disable-fixed-point
    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

http://en.wikipedia.org/wiki/Direction_flag
I think this was the reason:
http://lwn.net/Articles/272048/

>     --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
us.
 
> 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.

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---