Managed to compile glibc 2.13 for Alpha
Ioannis E. Venetis
venetis@capsl.udel.edu
Tue May 3 06:39:00 GMT 2011
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
More information about the crossgcc
mailing list