Date: Fri, 17 May 2013 20:47:04 +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: <20130517204704.5f98f4a2@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:

> These are questions in the first place for Natanael, but I'm sending
> to list because others may also have insight, or wish to hear the
> answers.

Hi, sorry for ignoring your previous emails. They came when i was short
on time and the they simply were to long and deep. :-/

It might help if you split up your questions in shorter emails (eg
part 1, part 2, etc)

> I've been wrestling for a couple of weeks getting ghc (Glasgow Haskell
> Compiler) to build on Alpine. I think I've succeeded, and I will write
> up the directions and put them on the wiki.

It would be nice.

>  If we can put the
> binaries I generated somewhere, then they can be used in an APKBUILD
> to bootstrap a build of newer versions of ghc. (Ghc needs a
> relatively-recent binary of ghc to build itself, else the compilation
> process is the more complex and arduous process that I went through.)

ugh, apps that needs bootstrapping are often problematic (gcc, and
openjdk)

> Anyways, as part of this write-up, I'm writing up an explanation of
> how I setup a cross-compiler inside an ArchLinux install (which, as it
> happens, was in a chroot on my Alpine box) to build binaries targeting
> Alpine.

Sounds complicated. You cannot build a native compiler in alpine?

Crosscompiling is a pretty complicated chapter, as you noticed. Last
time we did it was when we enabled NPTL in uclibc iirc.

> That's what the rest of this email is about; you can just
> ignore the background about Haskell/ghc.
> 
> I set up my cross-compiler using recent versions of buildroot (both
> the 2013.02 and 2013.05-rc2 releases). There were a couple of
> frustrating snags here, that I am trying to smooth out in my writeup.
> 
> One snag is that I had to do something like this on my Alpine box, to
> be able to execute the binaries that the cross-compiler generated:
> 
>   $ sudo ln -s libc.so.0.9.32 /lib/libc.so
>   $ sudo ln -s libuClibc-0.9.33.2.so /lib/libc.so.0
>   $ sudo ln -s libmpc.so.3 /usr/lib/libmpc.so
>   $ for f in ld-uClibc libcrypt libdl libm libpthread libresolv librt
>   libubacktrace libutil; do sudo ln -s $f-0.9.33.2.so /lib/$f.so.0;
> done
> 
> Anyone have ideas about how to eliminate the need to do this?

what does readelf -d say that SONAME is set to? Compare that with what
SONAME is in a native alpine linux.


> I examined the different configuration options that buildroot supplies
> when making its cross-compiling gcc, and the options that Alpine's
> APKBUILD uses. I thought it'd be a good idea to make buildroot
> approximate our native setup as closely as possible. However, to keep
> things from getting too complicated, I'm going to try to avoid
> applying the patches at
> http://distfiles.gentoo.org/distfiles/gcc-4.7.1-piepatches-v${_piepatchver}.tar.bz2.

Ok. That is for our hardened toolchain.

> With that in mind, here are my questions about our present APKBUILD
> (I'm looking at the APKBUILD for gcc-4.7.3-r6).
> 
> prepare() has the following:
>         #PR33200
>         sed -i 's/use_fixproto=yes/:/' gcc/config.gcc || return 1
> 
> This seems to be obsolete; see bottom of
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33200, also I've verified
> that this is a noop on the gcc/config.gcc in the gcc-4.7.3 sources.

Probably leftovers. Could you please create an issu for this on
bugs.a.o?
 
> Our sources has:
>         ...        
>         11_all_default-warn-format-security.patch
>         12_all_default-warn-trampolines.patch
>         15_all_libgomp-Werror.patch
>         16_all_libgo-Werror-pr53679.patch
>         29_all_arm_armv4t-default.patch
>         49_all_gcc-4.7-x86-libitm-pr52695.patch
>         51_all_libiberty-pic.patch
>         67_all_gcc-poison-system-directories.patch
>         74_all_gcc47_cloog-dl.patch
> 
>         gcc-spec-env.patch
>         pt_gnu_eh_frame.patch
>         uclibc-getipinfo.patch
>         gcc-4.7-dynamic-linker.patch
>         gcc-4.6-pr32219.patch
>         boehem-gc-uclibc.patch
>         gcc-pure64.patch
>         gcc-go.patch
>         "
> 
> The first block of patches all seem to come from
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/src/patchsets/gcc/4.7.3/gentoo/,
> however this doesn't include all of the patches available at that
> site. Should I assume that the rest of the patches available there
> have been reviewed and specifically rejected as not being relevant to
> Alpine, or introducing undesired changes?

Yes, I think I included some patches that I thought was not yet
relevant but probably soon would be (like the arm patches).

> What about the patches available at
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/src/patchsets/gcc/4.7.3/uclibc/?
> Buildroot includes all of those patches, but at a first glance, it
> seems like we don't include them? Are first appearances misleading
> here?

I haven't looked over those, so I cannot really comment on those. I
think our patches and the gentoo uclibc patches were closer when we
separated from gentoo (alpine 1.9). I think we didn't need them. We
might have same patches or corresponding patches with different names.

> What about the rest of the patches in our sources list: where do those
> come from? Were they generated by Alpine devs, or do they come from
> miscellaneous places? 

both I think.

> If anyone can venture a recommendation as to
> whether I should apply those patches (and also the earlier block of
> patches) to my cross-compiling gcc, I'd welcome the advice.

I'll comment from top of my head here bellow:
>         gcc-spec-env.patch

for the piepatches. It allow us to disable the enforced hardened flags
with GCC_SPECS env var.

>         pt_gnu_eh_frame.patch
>         uclibc-getipinfo.patch

Those I don't remember.

>         gcc-4.7-dynamic-linker.patch

I think this will be critical for you. It enables the
--with-dynamic-linker flag.

We added this when uclibc broke ABI. uClibc does not even try to be ABI
compatible sine the target embeded. We want to be able to upgrade, not
only reinstall so we need some kind of ABI stability. the first
releases had soname libc.so.0. This is hardcoded in gcc sources. when
ABI broke we decided to set soname to libc.so.0.9.32 and add an
additional package named libc0.9.32 so both uclibc and libc0.9.32
packges could be installed in parallel while upgrading.

since then the ABI have not broken again.

>         gcc-4.6-pr32219.patch

I don't remember. might be something uclibc devs found and reported. It
probably bite us at some point.

>         boehem-gc-uclibc.patch

I think this was to be able to compile stdc++ or gcc java.

>         gcc-pure64.patch

This patch dropped the /lib64 and /lib32 dirs for multiarch.

>         gcc-go.patch

Something for go-lang.

...

> I know there's a lot of info/questions here. I'd be glad for any
> partial answers, too.

I'll stop here for now. I'll try comment the rest in other email.

The --with-dynamic-linker is important as explained above. You will
also set a variable when building uclibc, ABI something.

I think it will be a good time for me to look over the toolchain soon.
Will upgrade gcc to 4.8.

Crosscompiling for ARM is also a hot topic, and so is musl instead of
uclibc.

Thanks!

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---