Re: Managed to compile glibc 2.13 for Alpha

["Ioannis E. Venetis" <venetis at capsl dot udel dot edu>]

Hello,

On 3/5/2011 1:14 πμ, Yann E. MORIN wrote:
> Ioannis, All,
>
> On Friday 29 April 2011 11:42:25 venetis@mail.capsl.udel.edu wrote:
> > I managed to compile glibc 2.13 for Alpha EV67.
>
> Thank you for pinging me on this! I'm sorry, I did not find time to
> do it earlier... :-(

I absolutely understand that your time is limited and that you are 
working on a voluntary basis on this.

> Anyway, it is not convenient to test those changes. Next time, could you
> please try to send proper Mercurial changesets (see the third entry in
> "docs/C - Misc. tutorials.txt" : "Using Mercurial to hack crosstool-NG").

I was not aware of this. I will try next time to it this way.

> Your changes are missing updates to the glibc config file to add the
> new version. With 'hg email', it would have been sent automatically.
> I'll add it manually here.
>
> > Specifically, the target
> > architecture is alphaev67-unknown-linux-gnu.
> > The rest of the toolchain consists of:
> > gcc 4.3.5
> > binutils 2.21
> > linux 2.6.38.3
> > gmp 5.0.1
> > mpfr 3.0.0
>
> Could please provide the .config you used so we can add it as a sample?
>
> > I had to add a few patches for Alpha (the four patches sent on 28/02/2011
> > here http://sourceware.org/ml/libc-ports/2011-02/) and modify a few
> > others. The only really problematic patch was 370-fnmatch.patch which I
> > could not modify to make it work, so I deleted it from the patchset.
>
> Did you check if it was applied (as is, or differently) upstream?

Although I know how to find a patch that I need (Google is my friend ;-) 
), I am not certain where and how I check for this. I have tried to 
understand how things work in glibc with respect to patches, but it is 
not my main concern and I have not spent too much time to figure it out. 
If someone can point me to the right direction I would appreciate it, so 
that I can check next time.

> > If you try any of these patchsets, don't forget during configuration of
> > crosstool-ng to go to the menu "C library" ->  "gcc extra flags" and add
> > the flag "-Wl,--no-relax".
>
> What's the purpose of that? Can't it be automated in some ways?
> I would like to rely as much as possible on the code (or at least on
> config knobs) for this kind of stuff. For example:
>    if [ "${arch}" = "alpha" -a "${other_condition}" = "y" ]; then
>      gcc_flags += "-Wl,--no-relax"
>    fi

I have no real knowledge of the internals of crosstool-ng. I imagined 
that it could be done somehow like this, but I found the work-around of 
adding it in the configuration.

> > I also had to select the option "Force unwind
> > support". The help says that the need for this option is architecture
> > dependant.
>
> Virtually, all ELF targets supported by crosstool-NG as unwinding,
> so *maybe* this should default to 'y'?...

I have no opinion on this :-)

> > Any chance to see these patchsets in the main branch of crosstool-ng?
>
> I'm working on it. :-)

Great! :-) Hopefully with the guidance you provided here I will make the 
adoption of patches easier for you next time!


> > PS1: Please refer to my previous message
> > (http://sourceware.org/ml/crossgcc/2011-03/msg00055.html) for the details
> > of what I changed/added in the 2.12.1 patchset)
> >
> > PS2: I have a few issues compiling a newer gcc (>= 4.4.x). The PPL library
> > gives me some problems (either that it cannot find version 4.3.1 of GMP or
> > if I select that specific version compilation ends because make cannot
> > find a rule to build a Java file). If anyone has any clue what might
> > happening here please let me know.
>
> Yes, there are many broken combinations. Currently, I think that choosing
> the latest versions of all companion libraries should be working. You will
> have to enable 'EXPERIMENTAL' in the 'Misc' menu.

Unfortunately it doesn't work for alpha :-( I had to disable the 
optimization of gcc 4.6.0 that uses the PPL library in order to compile 
it. As soon as I find some time I will have a closer look to see what's 
going on with this.

> I think we could probably do a cleanup pass to remove old versions, and
> keep only one/two version/s that we know is/are working...

Hm, I don't know about this. I have seen several projects (especially 
with simulators) that use older versions of these tools. I have no idea 
whether they are maintained or not, but this might cause some trouble. I 
use for example the whole range from gcc 4.3.5 up to 4.6.0 and glibc 
from 2.10.1 up to 2.13.

Best regards,

Ioannis E. Venetis

--
For unsubscribe information see http://sourceware.org/lists.html#faq