On Fri, 17 May 2013 13:07:20 -0400
Dubiousjim <lists+alpine-devel_at_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
> $ fgrep LARGEFILE main/libc0.9.32/uclibcconfig.x86*
> main/libc0.9.32/uclibcconfig.x86:# UCLIBC_HAS_FOPEN_LARGEFILE_MODE
> is not set
> UCLIBC_HAS_FOPEN_LARGEFILE_MODE is not set
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
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
> 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.
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.
to enable the genetoo hardened patches.
> 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:
This is to disable the exit with error when hit a gcc warning.
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.
I think this was the reason:
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:
> 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