Debian Bug report logs - #693208
clang unable to link trivial test program on armhf

grave

[Message part 1 (text/plain, inline)]
Package: clang
Version: 3.0-6
Severity: grave
Tags: patch
x-debbugs-cc: debian-release@lists.debian.org

RT in cc because of proposed TPU upload.

Unfortunately it seems that the changes in 3.0-6 fixed clang on armel
but not on armhf.

root@debian:/# clang -v test.c
Debian clang version 3.0-6 (tags/RELEASE_30/final) (based on LLVM 3.0)
Target: arm-unknown-linux-gnueabihf
Thread model: posix
clang: warning: unknown platform, assuming -mfloat-abi=soft
"/usr/bin/clang" -cc1 -triple armv4t-unknown-linux-gnueabihf -S
-disable-free -disable-llvm-verifier -main-file-name test.c
-mrelocation-model static -mdisable-fp-elim -mconstructor-aliases
-target-abi apcs-gnu -target-cpu arm7tdmi -msoft-float -mfloat-abi soft
-target-feature +soft-float -target-feature +soft-float-abi
-target-feature -neon -target-linker-version 2.22
-momit-leaf-frame-pointer -v -resource-dir /usr/bin/../lib/clang/3.0
-fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem
/usr/local/include -internal-isystem /usr/bin/../lib/clang/3.0/include
-internal-externc-isystem /usr/include/arm-linux-gnueabihf
-internal-externc-isystem /usr/include -ferror-limit 19 -fmessage-length
80 -fno-signed-char -fgnu-runtime -fobjc-runtime-has-arc
-fobjc-runtime-has-weak -fobjc-fragile-abi -fdiagnostics-show-option
-fcolor-diagnostics -o /tmp/test-TUFgUO.s -x c test.c
clang -cc1 version 3.0 based upon llvm 3.0 hosted on
arm-unknown-linux-gnueabihf
ignoring nonexistent directory "/usr/bin/../lib/clang/3.0/include"
ignoring nonexistent directory "/usr/bin/../lib/clang/3.0/include"
ignoring duplicate directory "/usr/local/include"
ignoring duplicate directory "/usr/include/arm-linux-gnueabihf"
ignoring duplicate directory "/usr/include/arm-linux-gnueabihf"
ignoring duplicate directory "/usr/include/arm-linux-gnueabihf"
ignoring duplicate directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/include/arm-linux-gnueabihf
/usr/include
/usr/include/clang/3.0/include/
/usr/lib/gcc/arm-linux-gnueabihf/4.6/include/
/usr/lib/gcc/arm-linux-gnueabihf/4.6/include-fixed/
End of search list.
"/usr/bin/as" -o /tmp/test-8d1iPt.o /tmp/test-TUFgUO.s
"/usr/bin/ld" -X --hash-style=both --build-id --eh-frame-hdr -m
armelf_linux_eabi -dynamic-linker /lib/ld-linux.so.3 -o a.out crt1.o
crti.o /usr/lib/gcc/arm-linux-gnueabihf/4.6/crtbegin.o
-L/usr/lib/gcc/arm-linux-gnueabihf/4.6
-L/usr/lib/gcc/arm-linux-gnueabihf/4.6/../../.. -L/lib -L/usr/lib
/tmp/test-8d1iPt.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc
--as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/arm-linux-gnueabihf/4.6/crtend.o crtn.o
/usr/bin/ld: cannot find crt1.o: No such file or directory
/usr/bin/ld: cannot find crti.o: No such file or directory
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
root@debian:/#

I decided to first look at the warning about float abi, this seems to
have been a simple case of a missing condition in the logic that decides
what float ABI to use. While fixing that I also noticed that the code
uses "softfp" by default on armel when for debian armel it should be
using "soft" by default (since debian supports hardware without a fpu)
so I changed that too.

Reading that code also gave me a hint on how to fix the code that made
the path descisions which I proceeded to do.

Then I had to fix the dynamic linker path for armhf.

This is sufficient to make clang work with the gold linker on armhf.
Unfortunately the bfd linker fails with an assertion failure. I intend
to file a seperate bug report about this but still I think working with
one or the two linker choices debian offers is better than working with
neither.

While working on the fixes I also found the clean target was not
cleaning up properly and so fixed it.

I have attatched a diff which I would like to upload to TPU are the
maintainer and release team happy with this? I have tested that the
patch does not break linking on armel with either bfd or gold.

P.S. it seems the version in unstable has regressed from the version
in testing and does not link a trivial test app successfully on either
armel or armhf I have not investigated details of that (IMO fixing
wheezy is more important than fixing a package that is in sid and
unlikely to make it for wheezy).

[clang.debdiff (text/plain, attachment)]
[Message part 1 (text/plain, inline)]
On Wed, Nov 14, 2012 at 09:24:50 +0000, peter green wrote:

> I have attatched a diff which I would like to upload to TPU are the
> maintainer and release team happy with this? I have tested that the
> patch does not break linking on armel with either bfd or gold.
> 
> P.S. it seems the version in unstable has regressed from the version
> in testing and does not link a trivial test app successfully on either
> armel or armhf I have not investigated details of that (IMO fixing
> wheezy is more important than fixing a package that is in sid and
> unlikely to make it for wheezy).
> 
Having a fix in sid is a prerequisite for anything regarding wheezy.

Cheers,
Julien

[signature.asc (application/pgp-signature, inline)]
On 14/11/2012 11:45, Julien Cristau wrote:
> On Wed, Nov 14, 2012 at 09:24:50 +0000, peter green wrote:
>
>> I have attatched a diff which I would like to upload to TPU are the
>> maintainer and release team happy with this? I have tested that the
>> patch does not break linking on armel with either bfd or gold.
>>
>> P.S. it seems the version in unstable has regressed from the version
>> in testing and does not link a trivial test app successfully on either
>> armel or armhf I have not investigated details of that (IMO fixing
>> wheezy is more important than fixing a package that is in sid and
>> unlikely to make it for wheezy).
>>
> Having a fix in sid is a prerequisite for anything regarding wheezy.
Unfortunately, we have clang 3.1 in sid (I failed to have this version
in Wheezy in time).

Otherwise, your patch look good. Thanks!
Sylvestre

On 14/11/2012 11:45, Julien Cristau wrote:
> On Wed, Nov 14, 2012 at 09:24:50 +0000, peter green wrote:
> 
>> I have attatched a diff which I would like to upload to TPU are the
>> maintainer and release team happy with this? I have tested that the
>> patch does not break linking on armel with either bfd or gold.
>>
>> P.S. it seems the version in unstable has regressed from the version
>> in testing and does not link a trivial test app successfully on either
>> armel or armhf I have not investigated details of that (IMO fixing
>> wheezy is more important than fixing a package that is in sid and
>> unlikely to make it for wheezy).
>>
> Having a fix in sid is a prerequisite for anything regarding wheezy.
So, to fix this issue, should I do the following ?

* ask for a removal of clang 3.1 in unstable
* upload a version 3.0 in unstable with Peter patch
* ask for an exception

Thanks
Sylvestre

[Message part 1 (text/plain, inline)]
Hello Sylvestre,

Installing clang and llvm-runtime packages on my Debian testing, here is
what I get :

$ cat hello.c
#include <stdio.h>
int main (void) {
        printf ("Hello, world!\n");
        return 0;
}
$ clang -emit-llvm -c hello.c && lli hello.o
lli: hello.o: unknown type in type table

However, installing llvm-3.1-runtime as well, 3.1 being the LLVM version
clang is based on, I get (forcing the lli version to 3.1) :

$ clang -emit-llvm -c hello.c && lli-3.1 hello.o
Hello, world!

I think asking our users to explicitly use versioned LLVM tools with clang
is wrong. In the future, I think you should base clang on the default LLVM
version, even if a newer LLVM version is available in the repositories.

Regarding the current clang packages in the repositories (3.0 in testing,
3.1 in unstable), you would have to add an epoch to downgrade clang to 3.0
in unstable with a fix and then have to fix migrated to testing. This would
also fix the issue above, but epochs are, well, not beautiful...

What is your opinion regarding those issues?

Cheers,
Arthur.

2012/11/26 Sylvestre Ledru <sylvestre@debian.org>

> On 14/11/2012 11:45, Julien Cristau wrote:
> > On Wed, Nov 14, 2012 at 09:24:50 +0000, peter green wrote:
> >
> >> I have attatched a diff which I would like to upload to TPU are the
> >> maintainer and release team happy with this? I have tested that the
> >> patch does not break linking on armel with either bfd or gold.
> >>
> >> P.S. it seems the version in unstable has regressed from the version
> >> in testing and does not link a trivial test app successfully on either
> >> armel or armhf I have not investigated details of that (IMO fixing
> >> wheezy is more important than fixing a package that is in sid and
> >> unlikely to make it for wheezy).
> >>
> > Having a fix in sid is a prerequisite for anything regarding wheezy.
> So, to fix this issue, should I do the following ?
>
> * ask for a removal of clang 3.1 in unstable
> * upload a version 3.0 in unstable with Peter patch
> * ask for an exception
>
> Thanks
> Sylvestre
>
> _______________________________________________
> Pkg-llvm-team mailing list
> Pkg-llvm-team@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-llvm-team
>

[Message part 2 (text/html, inline)]
On 26/11/2012 12:42, Arthur Loiret wrote:
> Hello Sylvestre,
> 
> Installing clang and llvm-runtime packages on my Debian testing, here is
> what I get :
> 
> $ cat hello.c
> #include <stdio.h>
> int main (void) {
>         printf ("Hello, world!\n");
>         return 0;
> }
> $ clang -emit-llvm -c hello.c && lli hello.o
> lli: hello.o: unknown type in type table
>
> However, installing llvm-3.1-runtime as well, 3.1 being the LLVM version
> clang is based on, I get (forcing the lli version to 3.1) :
> 
> $ clang -emit-llvm -c hello.c && lli-3.1 hello.o
> Hello, world!
I am not sure to see how it is related to the bug 693208 ?

> I think asking our users to explicitly use versioned LLVM tools with clang
> is wrong. In the future, I think you should base clang on the default LLVM
> version, even if a newer LLVM version is available in the repositories.
I don't understand what you mean:
In wheezy, llvm-default install llvm 3.0:
http://packages.debian.org/wheezy/llvm
and the version of clang in wheezy is 3.0:
http://packages.debian.org/wheezy/clang

> Regarding the current clang packages in the repositories (3.0 in testing,
> 3.1 in unstable), you would have to add an epoch to downgrade clang to 3.0
> in unstable with a fix and then have to fix migrated to testing. This would
> also fix the issue above, but epochs are, well, not beautiful...
> 
> What is your opinion regarding those issues?
I don't know. It is why I asked to the release team for guidance.

Sylvestre

Source: clang
Source-Version: 3.2~rc1-1~exp1

We believe that the bug you reported is fixed in the latest version of
clang, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 693208@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Sylvestre Ledru <sylvestre@debian.org> (supplier of updated clang package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Sat, 17 Nov 2012 15:31:19 +0100
Source: clang
Binary: clang clang-3.2 libclang1 libclang-dev libclang-common-dev compiler-rt
Architecture: source all amd64
Version: 3.2~rc1-1~exp1
Distribution: experimental
Urgency: low
Maintainer: LLVM Packaging Team <pkg-llvm-team@lists.alioth.debian.org>
Changed-By: Sylvestre Ledru <sylvestre@debian.org>
Description: 
 clang      - C, C++ and Objective-C compiler (LLVM based)
 clang-3.2  - C, C++ and Objective-C compiler (LLVM based)
 compiler-rt - Runtime C library - LLVM based
 libclang-common-dev - clang library - Common development package
 libclang-dev - clang library - Development package
 libclang1  - clang library
Closes: 666539 674155 685013 688811 691989 693208 693240
Changes: 
 clang (3.2~rc1-1~exp1) experimental; urgency=low
 .
   * New testing version
     - Fix when a bug when class with multiple copy constructors is in a union
       (Closes: #691989)
     - Improved support of C++ 11 (Closes: #666539)
   * Use gcc 4.7 to build clang (instead of 4.6) (Closes: #685013) (LP: #1081905)
   * Make asan (address sanitizer) work (Closes: #674155)
   * Make --coverage work (LP: #954709)
   * Also register clang for /usr/bin/c89 & /usr/bin/c99 (Closes: #688811)
   * Take in account the new gcc C++ paths (Closes: #693240)
   * Explicit dependency on libstdc++6-4.7-dev, libgcc-4.7-dev, libobjc-4.7-dev
     from clang. Thanks to new changes of gcc (4.7.2-10)
   * Enable parallel build when available
 .
   [ Peter Michael Green ]
   * 26-set-correct-float-abi.diff: Fix default float abis for armel and armhf
   * 24-path-multiarch.diff: Fix paths for armhf
     (Closes: #693208)
Checksums-Sha1: 
 65c4b1799114f16dab3c4e5313401a569e1f1d29 2096 clang_3.2~rc1-1~exp1.dsc
 a96dd5bf431cf9c12bbdeb129261f71997418d7c 1027210 clang_3.2~rc1.orig-compiler-rt.tar.bz2
 24991d6b7e1973122b96da0d1b09deee8f6a8ab4 6987407 clang_3.2~rc1.orig.tar.bz2
 b058355729d25b6484ca58887aefbbdd6a3bb5ea 17079 clang_3.2~rc1-1~exp1.debian.tar.gz
 5c8e70f30afe3a145011fe04119196a77e33ccca 8818 clang_3.2~rc1-1~exp1_all.deb
 89c90f1ccbb42bd2cb4de496263cafda76244f3a 6074666 clang-3.2_3.2~rc1-1~exp1_amd64.deb
 60fe6f35897e6ce940a834c6c39cbc1e81caa90e 4188608 libclang1_3.2~rc1-1~exp1_amd64.deb
 62cddf76e81505d48e41169136001f617e632e62 10561744 libclang-dev_3.2~rc1-1~exp1_amd64.deb
 9760798bd189c9823c988778eb237324cb574a86 301942 libclang-common-dev_3.2~rc1-1~exp1_amd64.deb
 7b19d19e6999a41d49d774413c09dddcaabbb0f7 204118 compiler-rt_3.2~rc1-1~exp1_amd64.deb
Checksums-Sha256: 
 dfe749ae0a1f92401125f18597e6ac54103c5c4e78c1b96af404504ab6126d29 2096 clang_3.2~rc1-1~exp1.dsc
 4054447416c5f5e9aad6d93a28dd8c4722c15cb8fbc8f9ddfd9b83fe21e14505 1027210 clang_3.2~rc1.orig-compiler-rt.tar.bz2
 6148949506ce246c29e53e63755583691a8433d356bd0a3ebdeee829c185f828 6987407 clang_3.2~rc1.orig.tar.bz2
 32851b2e999c131b9597707d53c9565a3e8703c90faa3b8a67a2f81c8c930e8a 17079 clang_3.2~rc1-1~exp1.debian.tar.gz
 3a59980bbb51f29975a59d97a9fcbad78cb894ccb29e07aff5423ab7efd8fb90 8818 clang_3.2~rc1-1~exp1_all.deb
 09870b2b4a5f8c25d13e4433c65af4b90c28a021e51f141bf38b5ccb619e6303 6074666 clang-3.2_3.2~rc1-1~exp1_amd64.deb
 607be2654ddffd66ef086127c94f4d11b695bb9be3e9dcbbc55869f8425fc1ca 4188608 libclang1_3.2~rc1-1~exp1_amd64.deb
 1a78582c2c49dc824cfa76696bee796f30139cc7c096180ee67f1dd7765d4933 10561744 libclang-dev_3.2~rc1-1~exp1_amd64.deb
 5a55a6e01f709c05ab453547b85124b1fae2b2c7479fa193e751443e5734892d 301942 libclang-common-dev_3.2~rc1-1~exp1_amd64.deb
 e5a773670f0dc533343db778309609d58853d6e5cc678cd895fefc5aaa459522 204118 compiler-rt_3.2~rc1-1~exp1_amd64.deb
Files: 
 40f1789ba53c794c2695f1b00c37c8ef 2096 devel optional clang_3.2~rc1-1~exp1.dsc
 76914ad7b0d74d29ec4a783c81ae200b 1027210 devel optional clang_3.2~rc1.orig-compiler-rt.tar.bz2
 a4e586486a78acee0637785b18890128 6987407 devel optional clang_3.2~rc1.orig.tar.bz2
 17b1ef74345faac1082205c7d19aafff 17079 devel optional clang_3.2~rc1-1~exp1.debian.tar.gz
 614231cd3f2f899c177506ed892b9612 8818 devel optional clang_3.2~rc1-1~exp1_all.deb
 019d70d30fe48098366b9250deed3f62 6074666 devel optional clang-3.2_3.2~rc1-1~exp1_amd64.deb
 a7482d13e75411db475b4b1e24ba4f98 4188608 devel optional libclang1_3.2~rc1-1~exp1_amd64.deb
 21a0465544319bfeb31c772b262ff9ba 10561744 libdevel optional libclang-dev_3.2~rc1-1~exp1_amd64.deb
 2fae0b9679ade8096929a388a0769647 301942 libdevel optional libclang-common-dev_3.2~rc1-1~exp1_amd64.deb
 c98d6b427ac8db596cea409d08fd6808 204118 libdevel optional compiler-rt_3.2~rc1-1~exp1_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlC3UEUACgkQiOXXM92JlhBXLgCgz+TTiRAFQFaFqdkU2+GSKl9j
I2EAoKbjUTq1SZM8chc4DkBrv3+56SkQ
=Woei
-----END PGP SIGNATURE-----

On Mon, 26 Nov 2012 13:25:12 +0100
Sylvestre Ledru <sylvestre@debian.org> wrote:
> > Regarding the current clang packages in the repositories (3.0 in
> > testing, 3.1 in unstable), you would have to add an epoch to
> > downgrade clang to 3.0 in unstable with a fix and then have to fix
> > migrated to testing. This would also fix the issue above, but
> > epochs are, well, not beautiful...
> > 
> > What is your opinion regarding those issues?
> I don't know. It is why I asked to the release team for guidance.
IMO, the correct way to deal with this is to prepare an upload of clang
3.0-7 (currently in testing is 3.0-6) which includes *ONLY* the fix
necessary for closing this bugreport. I have looked at both versions
(3.0-6 and 3.2~rc3), but I can’t say for sure which change it is.

Afterwards, generate a debdiff between clang_3.0-6.dsc and
clang_3.0-7.dsc and attach it to this bugreport, asking the release
team for approval to upload it to testing-proposed-updates.

See also:
http://www.debian.org/doc/manuals/developers-reference/pkgs.html#t-p-u
http://release.debian.org/wheezy/freeze_policy.html

-- 
Best regards,
Michael

[Message part 1 (text/plain, inline)]
On Mon, Nov 26, 2012 at 11:40:06 +0100, Sylvestre Ledru wrote:

> So, to fix this issue, should I do the following ?
> 
> * ask for a removal of clang 3.1 in unstable
> * upload a version 3.0 in unstable with Peter patch
> * ask for an exception
> 
I'm not sure what the point of your first step would be.  But yes, to
fix this issue you need to upload a fix to sid, and then either get that
fix migrated or get a fix in to tpu.  Why is this so hard?

Cheers,
Julien

[signature.asc (application/pgp-signature, inline)]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 29/12/2012 18:24, Julien Cristau wrote:
> On Mon, Nov 26, 2012 at 11:40:06 +0100, Sylvestre Ledru wrote:
> 
>> So, to fix this issue, should I do the following ?
>> 
>> * ask for a removal of clang 3.1 in unstable * upload a version
>> 3.0 in unstable with Peter patch * ask for an exception
>> 
> I'm not sure what the point of your first step would be.  But yes,
> to fix this issue you need to upload a fix to sid, and then either
> get that fix migrated or get a fix in to tpu.  Why is this so
> hard?
Because the version in unstable is 3.1 and in testing, we have 3.0.

If I upload a 3.0 in unstable, I guess it is going to be rejected,
isn't it ?

Sylvestre

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlDgNZ8ACgkQiOXXM92JlhAmUwCfa5iVhoJLYTb7oHsO0adb0j7K
Z9UAnRH4VR+H0BSbQ1qKSJpFjRAGQd1W
=YtJW
-----END PGP SIGNATURE-----

[Message part 1 (text/plain, inline)]
On Sun, Dec 30, 2012 at 13:37:51 +0100, Sylvestre Ledru wrote:

> On 29/12/2012 18:24, Julien Cristau wrote:
> > On Mon, Nov 26, 2012 at 11:40:06 +0100, Sylvestre Ledru wrote:
> > 
> >> So, to fix this issue, should I do the following ?
> >> 
> >> * ask for a removal of clang 3.1 in unstable * upload a version
> >> 3.0 in unstable with Peter patch * ask for an exception
> >> 
> > I'm not sure what the point of your first step would be.  But yes,
> > to fix this issue you need to upload a fix to sid, and then either
> > get that fix migrated or get a fix in to tpu.  Why is this so
> > hard?
> Because the version in unstable is 3.1 and in testing, we have 3.0.
> 
> If I upload a 3.0 in unstable, I guess it is going to be rejected,
> isn't it ?
> 
- Not with an epoch
- Removing stuff isn't going to change that anyway

Cheers,
Julien

[signature.asc (application/pgp-signature, inline)]
[Message part 1 (text/plain, inline)]
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: tpu

Hello,

I would like to upload clang/3.0-6.1+deb7u0 to testing-proposed-updates
to fix #693208 in wheezy. At the moment, 3.0-6 is in testing, 3.1-8 is
in unstable.

#693208 is about clang failing to produce a trivial binarey on armhf. I
have verified that the fixes work in an armhf qemu chroot. All patches
have been merged upstream, too, so I am fairly confident they do the
right thing.

Since by now we have gcc-4.7 in Debian, I also needed to apply this
patch from upstream, otherwise clang segfaults when building software
(e.g. i3-wm): http://llvm.org/bugs/show_bug.cgi?id=11926#c17

The debdiff is attached.

May I go ahead?

-- 
Best regards,
Michael

[clang.debdiff (application/octet-stream, attachment)]
On 06/02/2013 14:27, Michael Stapelberg wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian.org@packages.debian.org
> Usertags: tpu
> 
> Hello,
> 
> I would like to upload clang/3.0-6.1+deb7u0 to testing-proposed-updates
> to fix #693208 in wheezy. At the moment, 3.0-6 is in testing, 3.1-8 is
> in unstable.
> 
> #693208 is about clang failing to produce a trivial binarey on armhf. I
> have verified that the fixes work in an armhf qemu chroot. All patches
> have been merged upstream, too, so I am fairly confident they do the
> right thing.
> 
> Since by now we have gcc-4.7 in Debian, I also needed to apply this
> patch from upstream, otherwise clang segfaults when building software
> (e.g. i3-wm): http://llvm.org/bugs/show_bug.cgi?id=11926#c17
> 
> The debdiff is attached.
> 
> May I go ahead?
Yes, many thanks.

Sylvestre

On Wed, 2013-02-06 at 22:28 +0100, Michael Stapelberg wrote:
> "Adam D. Barratt" <adam@adam-barratt.org.uk> writes:
> > What's the status of getting this fixed in unstable, as already
> > requested by Julien in #693208?
> Why is it necessary to fix this in unstable? This’d require introducing
> an epoch. Let me know if you insist on it, but I don’t understand why
> this is important.

I wasn't particularly suggesting re-introducing 3.0 to unstable.
However, given that packages from tpu get essentially no testing at all
(no pun intended) before hitting testing, being able to prove a patch in
unstable first avoids a number of (admittedly not all) potential issues.

Looking at the proposed tpu diff and the 3.0 -> 3.1 diff, it looks like
the armhf changes should apply "as is" to 3.1; has anyone tried that?

Regards,

Adam

Hi Adam,

"Adam D. Barratt" <adam@adam-barratt.org.uk> writes:
> I wasn't particularly suggesting re-introducing 3.0 to unstable.
> However, given that packages from tpu get essentially no testing at all
> (no pun intended) before hitting testing, being able to prove a patch in
> unstable first avoids a number of (admittedly not all) potential
> issues.
Now I understand what your point was, thanks for clarifying.

> Looking at the proposed tpu diff and the 3.0 -> 3.1 diff, it looks like
> the armhf changes should apply "as is" to 3.1; has anyone tried that?
I have ported the patches from 3.0 to 3.1 and successfully built the
package on amd64, where it works.

Therefore, I will now build it on armhf, which will take around a day.

Sylvestre: Are you okay with me NMUing clang 3.1-8.1 to unstable in
order to expose my changes to a wider audience before we do the fix via
t-p-u?

-- 
Best regards,
Michael

Le 02/07/13 13:15, Michael Stapelberg a écrit :
> Hi Adam,
>
> "Adam D. Barratt" <adam@adam-barratt.org.uk> writes:
>> Looking at the proposed tpu diff and the 3.0 -> 3.1 diff, it looks like
>> the armhf changes should apply "as is" to 3.1; has anyone tried that?
> I have ported the patches from 3.0 to 3.1 and successfully built the
> package on amd64, where it works.
>
> Therefore, I will now build it on armhf, which will take around a day.
>
> Sylvestre: Are you okay with me NMUing clang 3.1-8.1 to unstable in
> order to expose my changes to a wider audience before we do the fix via
> t-p-u?
>
Please go ahread. :)

Thanks again,
Sylvestre

Hi Adam,

Michael Stapelberg <stapelberg@debian.org> writes:
> Therefore, I will now build it on armhf, which will take around a day.
Update: the armhf build failed because about 100 testcases fail.

I have no clue on how to fix this and can’t spend much more time on
debugging this either.

Given that the 3.0 version works — it passed all the clang tests and can
compile non-trivial software on armhf and amd64 — can we just upload
that? Or, as a last resort, re-introduce 3.0 in unstable, even if
switching to an epoch is ugly?

-- 
Best regards,
Michael

Le 02/07/13 18:07, Michael Stapelberg a écrit :
> Hi Adam,
>
> Michael Stapelberg <stapelberg@debian.org> writes:
>> Therefore, I will now build it on armhf, which will take around a day.
> Update: the armhf build failed because about 100 testcases fail.
>
> I have no clue on how to fix this and can’t spend much more time on
> debugging this either.
>
> Given that the 3.0 version works — it passed all the clang tests and can
> compile non-trivial software on armhf and amd64 — can we just upload
> that? Or, as a last resort, re-introduce 3.0 in unstable, even if
> switching to an epoch is ugly?
>
Don't bother too much about the epoch, clang source package is going to
be removed anyway...
(I am working on a LLVM toolchain package including llvm + clang + other
stuff).

Sylvestre

On Thu, 2013-02-07 at 19:29 +0100, Sylvestre Ledru wrote:
> Le 02/07/13 18:07, Michael Stapelberg a écrit :
>> Update: the armhf build failed because about 100 testcases fail.

Hmm, presumably it worked at some point, given there are armhf binaries
in unstable. :-(

> > Given that the 3.0 version works — it passed all the clang tests and can
> > compile non-trivial software on armhf and amd64 — can we just upload
> > that? Or, as a last resort, re-introduce 3.0 in unstable, even if
> > switching to an epoch is ugly?
> >
> Don't bother too much about the epoch, clang source package is going to
> be removed anyway...

Given that 3.1 appears never to have managed to build on several
architectures in unstable (a regression in each case) and that I assume
the intention would be to introduce 3.2 to unstable after the release,
then if Sylvestre's not opposed reintroducing a fixed 3.0 to sid
temporarily may be the sanest answer.

Regards,

Adam

Hi Adam,

"Adam D. Barratt" <adam@adam-barratt.org.uk> writes:
> Hmm, presumably it worked at some point, given there are armhf binaries
> in unstable. :-(
Ack. My guess is that it worked with gcc 4.6.

> Given that 3.1 appears never to have managed to build on several
> architectures in unstable (a regression in each case) and that I assume
> the intention would be to introduce 3.2 to unstable after the release,
> then if Sylvestre's not opposed reintroducing a fixed 3.0 to sid
> temporarily may be the sanest answer.
I just uploaded 1:3.0-6.1 to unstable. I presume you want me to close
this bug and open an unblock request instead, right? :)

-- 
Best regards,
Michael

Debian Bug report logs - #693208 clang unable to link trivial test program on armhf

Debian Bug report logs - #693208
clang unable to link trivial test program on armhf