llvm dev - Aug 2009 - [LLVMdev] llvm-gcc-4.2-2.5 fails to build from source on arm: MACHO_DYNAMIC_NO_PIC_P undeclared

On 8/3/09, Anton Korobeynikov <anton at korobeynikov.info>
wrote:
>  > Thanks. Do you have fixes for the other ARM bloopers? This is the
>  > forthcoming Debian version and it's now dying on arm-gnueabi when
it
>  > links cc1-dummy saying
>
> Please use the current Top-of-the-Tree version.
Sorry, that's not an option as I'm trying to fix the Debian version,
which uses "stable" releases. Each Debian build takes 6 hours, so
finding and fixing these bugs one by one is quite a long process.

llvm-gcc-4.2-2.5 is failing to build from source on arm, sparc,
powerpc and ia64, only succeeding on i386 and amd64:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=llvm-gcc-4.2;dist=unstable
so it looks like the 2.5 release was never properly tested before it
was published.

If the issues and fixes are "known", can you make them known to the
public, for example by producing a 2.5.1 with the worst bugs fixed, or
by documenting the issues and patches in the "Known problems" section?
It would be a big help to all the distro maintainers.

Thanks & sorry to be the bringer of bad news...

   M

Hello, Martin
> llvm-gcc-4.2-2.5 is failing to build from source on arm, sparc,
> powerpc and ia64, only succeeding on i386 and amd64:
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=llvm-gcc-4.2;dist=unstable
> so it looks like the 2.5 release was never properly tested before it
> was published.
Unfortunately, ia64 and sparc were never considered as a 'tier-1'
targets for llvm-gcc, there was noone who cared about it. Also, our
linux resources are pretty limited, thus both ppc and arm were broken
at the time for 2.5 release.

Hopefully things will be much better with the coming 2.6 release, at
least one might expect arm and ppc to be more or less ok. ia64 support
was completely dropped and sparc should be brokens as of time of 2.5.
> If the issues and fixes are "known", can you make them known to
the
> public, for example by producing a 2.5.1 with the worst bugs fixed, or
> by documenting the issues and patches in the "Known problems"
section?
> It would be a big help to all the distro maintainers.
You might want to stick with next 2.6 release, which is scheduled to
be out within next 1.5 months

I would like to comment on some other bugs as well:
478535: there are no plans to support of legacy IBM S390 platform,
only 64 bit one (that's s390x in tartget triple). The current plans
are to use clang only, not llvm-gcc, however I might be able to find
few hours to give llvm-gcc a try.
539496: There are no plans to support ARMv4 in LLVM. As for ToT ARM
builds of llvm-gcc (both for bare-metal arm-elf and normal
arm-none-linux-gnueabi triples) is broken due to two PRs: 4680, 4681
511721: I believe it should be fixed on ToT.
518592: Sounds like compiler / linker problem, it's not LLVM related at all

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

On 8/4/09, Anton Korobeynikov <anton at korobeynikov.info>
wrote:
> both ppc and arm were broken at the time for 2.5 release.
Ah, OK, thanks. That resolves my problem! :)

I've edited your remarks and appended them to the debian bug report,
which should solve the issue, see bugs.debian.org/539496
>  I would like to comment on some other bugs as well:
>  478535: there are no plans to support of legacy IBM S390 platform,
>  only 64 bit one (that's s390x in tartget triple). The current plans
>  are to use clang only, not llvm-gcc, however I might be able to find
>  few hours to give llvm-gcc a try.
>  539496: There are no plans to support ARMv4 in LLVM. As for ToT ARM
>  builds of llvm-gcc (both for bare-metal arm-elf and normal
>  arm-none-linux-gnueabi triples) is broken due to two PRs: 4680, 4681
>  511721: I believe it should be fixed on ToT.
>  518592: Sounds like compiler / linker problem, it's not LLVM related
at all
Thanks. I've forwarded these comments to the bug tracker.
In general. anyone can add comments to Debian bug reports simply by
sending email to 478535 at bugs.debian.org or whatever

With respect to 539496, yes, all major distributions are moving to ARM
EABI, for which the minimum architecture is armv4t, while armv4 is
becoming rare.
But if you also mean "no plans to support ARMv4t", I would say that it
is currently very common in small devices where a compiler with a
small memory requirement and producing compact object code is most
valuable. Exmples: the openmoko linux phone and the many single-board
ARM computers currently on the market.
The only incompatability that ARMv5t causes is the extra
count-leading-zeros instruction, which is seldom useful to a compiler
except in asm code for division - a small gain - so I would urge LLVM
to continue support for ARMv4t unless there are compelling reasons not
to do so.
But I may have misunderstood you.

Re: resources, there is a 600MHz 512MB ARM (v5t) here, as well as a
little armv4t board, which are on 24/7 and which I am happy for people
to use over ssh to debug arm and arm-eabi issues. If that would be
useful to anyone, just send mail privately suggesting a username

Thanks again

   M

On Aug 4, 2009, at 5:33 AM, Anton Korobeynikov wrote:
> Hello, Martin
>
>> llvm-gcc-4.2-2.5 is failing to build from source on arm, sparc,
>> powerpc and ia64, only succeeding on i386 and amd64:
>>
http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=llvm-gcc-4.2;dist=unstable
>> so it looks like the 2.5 release was never properly tested before it
>> was published.
> Unfortunately, ia64 and sparc were never considered as a 'tier-1'
> targets for llvm-gcc, there was noone who cared about it. Also, our
> linux resources are pretty limited, thus both ppc and arm were broken
> at the time for 2.5 release.
>
> Hopefully things will be much better with the coming 2.6 release, at
> least one might expect arm and ppc to be more or less ok. ia64 support
> was completely dropped and sparc should be brokens as of time of 2.5.
>
I just want to comment on this. We test our releases very throughly  
for supported targets. Supported means that they are actively  
maintained and tested day after day. If no one steps up to be a  
maintainer for these targets, then they will not become a part of the  
release criteria.

With that said, we only qualified for x86-32, x86-64, mingw32, and ppc  
(mac os 10.5 only).  So pretty much all the ones that are failing were  
not supported for 2.5. This list is only slightly expanded for 2.6,  
and will not include arm, ia64, sparc, or ppc. arm will probably work  
with 2.5, but unless someone wants to qualify it for the release (I do  
not have a volunteer), then it will not be on the list of supported  
targets.

We'd love help with these targets. Ideally, we need someone to set up  
an appropriate buildbot and actively monitor it and fix issues or file  
bug reports for things that come up.

Thanks,
Tanya

>> If the issues and fixes are "known", can you make them known
to the
>> public, for example by producing a 2.5.1 with the worst bugs fixed,  
>> or
>> by documenting the issues and patches in the "Known problems"
>> section?
>> It would be a big help to all the distro maintainers.
> You might want to stick with next 2.6 release, which is scheduled to
> be out within next 1.5 months
>
> I would like to comment on some other bugs as well:
> 478535: there are no plans to support of legacy IBM S390 platform,
> only 64 bit one (that's s390x in tartget triple). The current plans
> are to use clang only, not llvm-gcc, however I might be able to find
> few hours to give llvm-gcc a try.
> 539496: There are no plans to support ARMv4 in LLVM. As for ToT ARM
> builds of llvm-gcc (both for bare-metal arm-elf and normal
> arm-none-linux-gnueabi triples) is broken due to two PRs: 4680, 4681
> 511721: I believe it should be fixed on ToT.
> 518592: Sounds like compiler / linker problem, it's not LLVM related  
> at all
>
> -- 
> With best regards, Anton Korobeynikov
> Faculty of Mathematics and Mechanics, Saint Petersburg State  
> University
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090819/6f00bb7d/attachment.html>