[opensuse-arm] libqt4 failed
Hi, libqt4 failed to build for both armv5 and armv7 in Factory. For armv7, it seems to be due to build-armv7-with-double-qreal.diff patch which lead to a double declaration of a function. I think we should instead use "-fpu no" (or softvfp, vfpv2 or softvfp+vfpv2?) option for configure? But I am not sure it will be really used. For armv5, the compiler does not find the file "bits/c++config.h" whereas the package libstdc++47-devel is installed: ******************************************************************************** [ 531s] In file included from /home/abuild/rpmbuild/BUILD/qt-everywhere-opensource-src-4.8.2/include/QtCore/../../src/corelib/tools/qlist.h:58:0, [ 531s] from /home/abuild/rpmbuild/BUILD/qt-everywhere-opensource-src-4.8.2/include/QtCore/qlist.h:1, [ 531s] from /home/abuild/rpmbuild/BUILD/qt-everywhere-opensource-src-4.8.2/include/QtCore/../../src/corelib/tools/qstringlist.h:47, [ 531s] from /home/abuild/rpmbuild/BUILD/qt-everywhere-opensource-src-4.8.2/include/QtCore/qstringlist.h:1, [ 531s] from project.h:45, [ 531s] from option.h:45, [ 531s] from property.cpp:43: [ 531s] /usr/armv5el-suse-linux-gnueabi/usr/include/c++/4.7/new:41:28: fatal error: bits/c++config.h: No such file or directory ******************************************************************************** Any idea why? Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 09/17/2012 12:30 PM, Guillaume GARDET wrote:
For armv5, the compiler does not find the file "bits/c++config.h" whereas the package libstdc++47-devel is installed: ********************************************************************************
[ 531s] In file included from /home/abuild/rpmbuild/BUILD/qt-everywhere-opensource-src-4.8.2/include/QtCore/../../src/corelib/tools/qlist.h:58:0,
[ 531s] from /home/abuild/rpmbuild/BUILD/qt-everywhere-opensource-src-4.8.2/include/QtCore/qlist.h:1,
[ 531s] from /home/abuild/rpmbuild/BUILD/qt-everywhere-opensource-src-4.8.2/include/QtCore/../../src/corelib/tools/qstringlist.h:47,
[ 531s] from /home/abuild/rpmbuild/BUILD/qt-everywhere-opensource-src-4.8.2/include/QtCore/qstringlist.h:1,
[ 531s] from project.h:45, [ 531s] from option.h:45, [ 531s] from property.cpp:43: [ 531s] /usr/armv5el-suse-linux-gnueabi/usr/include/c++/4.7/new:41:28: fatal error: bits/c++config.h: No such file or directory ********************************************************************************
using strace, I found that the file is searched in /usr/armv5el-suse-linux-gnueabi/usr/include/c++/4.7/bits/c++config.h /usr/armv5el-suse-linux-gnueabi/usr/include/c++/4.7/backward/bits/c++config.h /usr/lib64/gcc/armv5el-suse-linux-gnueabi/4.7/include/bits/c++config.h /usr/armv5el-suse-linux-gnueabi/usr/local/include/bits/c++config.h /usr/lib64/gcc/armv5el-suse-linux-gnueabi/4.7/include-fixed/bits/c++config.h /usr/armv5el-suse-linux-gnueabi/usr/include/bits/c++config.h but it really is in /usr/include/c++/4.7/armv5tel-suse-linux-gnueabi/bits/c++config.h Ciao Bernhard M. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 19.09.2012, at 12:07, Bernhard M. Wiedemann wrote:
On 09/17/2012 12:30 PM, Guillaume GARDET wrote:
For armv5, the compiler does not find the file "bits/c++config.h" whereas the package libstdc++47-devel is installed: ********************************************************************************
[ 531s] In file included from /home/abuild/rpmbuild/BUILD/qt-everywhere-opensource-src-4.8.2/include/QtCore/../../src/corelib/tools/qlist.h:58:0,
[ 531s] from /home/abuild/rpmbuild/BUILD/qt-everywhere-opensource-src-4.8.2/include/QtCore/qlist.h:1,
[ 531s] from /home/abuild/rpmbuild/BUILD/qt-everywhere-opensource-src-4.8.2/include/QtCore/../../src/corelib/tools/qstringlist.h:47,
[ 531s] from /home/abuild/rpmbuild/BUILD/qt-everywhere-opensource-src-4.8.2/include/QtCore/qstringlist.h:1,
[ 531s] from project.h:45, [ 531s] from option.h:45, [ 531s] from property.cpp:43: [ 531s] /usr/armv5el-suse-linux-gnueabi/usr/include/c++/4.7/new:41:28: fatal error: bits/c++config.h: No such file or directory ********************************************************************************
using strace, I found that the file is searched in
/usr/armv5el-suse-linux-gnueabi/usr/include/c++/4.7/bits/c++config.h /usr/armv5el-suse-linux-gnueabi/usr/include/c++/4.7/backward/bits/c++config.h /usr/lib64/gcc/armv5el-suse-linux-gnueabi/4.7/include/bits/c++config.h /usr/armv5el-suse-linux-gnueabi/usr/local/include/bits/c++config.h /usr/lib64/gcc/armv5el-suse-linux-gnueabi/4.7/include-fixed/bits/c++config.h /usr/armv5el-suse-linux-gnueabi/usr/include/bits/c++config.h
but it really is in /usr/include/c++/4.7/armv5tel-suse-linux-gnueabi/bits/c++config.h
Is the armv5el / armv5tel difference on purpose? Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 19/09/2012 12:09, Alexander Graf a écrit :
On 19.09.2012, at 12:07, Bernhard M. Wiedemann wrote:
On 09/17/2012 12:30 PM, Guillaume GARDET wrote:
For armv5, the compiler does not find the file "bits/c++config.h" whereas the package libstdc++47-devel is installed: ********************************************************************************
[ 531s] In file included from /home/abuild/rpmbuild/BUILD/qt-everywhere-opensource-src-4.8.2/include/QtCore/../../src/corelib/tools/qlist.h:58:0,
[ 531s] from /home/abuild/rpmbuild/BUILD/qt-everywhere-opensource-src-4.8.2/include/QtCore/qlist.h:1,
[ 531s] from /home/abuild/rpmbuild/BUILD/qt-everywhere-opensource-src-4.8.2/include/QtCore/../../src/corelib/tools/qstringlist.h:47,
[ 531s] from /home/abuild/rpmbuild/BUILD/qt-everywhere-opensource-src-4.8.2/include/QtCore/qstringlist.h:1,
[ 531s] from project.h:45, [ 531s] from option.h:45, [ 531s] from property.cpp:43: [ 531s] /usr/armv5el-suse-linux-gnueabi/usr/include/c++/4.7/new:41:28: fatal error: bits/c++config.h: No such file or directory ********************************************************************************
using strace, I found that the file is searched in
/usr/armv5el-suse-linux-gnueabi/usr/include/c++/4.7/bits/c++config.h /usr/armv5el-suse-linux-gnueabi/usr/include/c++/4.7/backward/bits/c++config.h /usr/lib64/gcc/armv5el-suse-linux-gnueabi/4.7/include/bits/c++config.h /usr/armv5el-suse-linux-gnueabi/usr/local/include/bits/c++config.h /usr/lib64/gcc/armv5el-suse-linux-gnueabi/4.7/include-fixed/bits/c++config.h /usr/armv5el-suse-linux-gnueabi/usr/include/bits/c++config.h
but it really is in /usr/include/c++/4.7/armv5tel-suse-linux-gnueabi/bits/c++config.h Is the armv5el / armv5tel difference on purpose?
Does anyone have some ideas to solve the problem? There are more packages affected. I would like to help, but I do not know which package is faulty. Guillaume
Alex
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 05.10.2012, at 10:49, Guillaume Gardet <guillaume.gardet@free.fr> wrote:
Le 19/09/2012 12:09, Alexander Graf a écrit :
On 19.09.2012, at 12:07, Bernhard M. Wiedemann wrote:
On 09/17/2012 12:30 PM, Guillaume GARDET wrote:
For armv5, the compiler does not find the file "bits/c++config.h" whereas the package libstdc++47-devel is installed: ********************************************************************************
[ 531s] In file included from /home/abuild/rpmbuild/BUILD/qt-everywhere-opensource-src-4.8.2/include/QtCore/../../src/corelib/tools/qlist.h:58:0,
[ 531s] from /home/abuild/rpmbuild/BUILD/qt-everywhere-opensource-src-4.8.2/include/QtCore/qlist.h:1,
[ 531s] from /home/abuild/rpmbuild/BUILD/qt-everywhere-opensource-src-4.8.2/include/QtCore/../../src/corelib/tools/qstringlist.h:47,
[ 531s] from /home/abuild/rpmbuild/BUILD/qt-everywhere-opensource-src-4.8.2/include/QtCore/qstringlist.h:1,
[ 531s] from project.h:45, [ 531s] from option.h:45, [ 531s] from property.cpp:43: [ 531s] /usr/armv5el-suse-linux-gnueabi/usr/include/c++/4.7/new:41:28: fatal error: bits/c++config.h: No such file or directory ********************************************************************************
using strace, I found that the file is searched in
/usr/armv5el-suse-linux-gnueabi/usr/include/c++/4.7/bits/c++config.h /usr/armv5el-suse-linux-gnueabi/usr/include/c++/4.7/backward/bits/c++config.h /usr/lib64/gcc/armv5el-suse-linux-gnueabi/4.7/include/bits/c++config.h /usr/armv5el-suse-linux-gnueabi/usr/local/include/bits/c++config.h /usr/lib64/gcc/armv5el-suse-linux-gnueabi/4.7/include-fixed/bits/c++config.h /usr/armv5el-suse-linux-gnueabi/usr/include/bits/c++config.h
but it really is in /usr/include/c++/4.7/armv5tel-suse-linux-gnueabi/bits/c++config.h Is the armv5el / armv5tel difference on purpose?
Does anyone have some ideas to solve the problem? There are more packages affected.
I would like to help, but I do not know which package is faulty.
IIRC the problem lies in qemu-accel and the fact that we call it armv5tel, but it really is armv5el (no thumb). Adrian wanted to switch it to armv5el completely, to get rid of that naming difference. Alex
Guillaume
Alex
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 05/10/2012 12:27, Alexander Graf a écrit :
On 05.10.2012, at 10:49, Guillaume Gardet <guillaume.gardet@free.fr> wrote:
Le 19/09/2012 12:09, Alexander Graf a écrit :
On 19.09.2012, at 12:07, Bernhard M. Wiedemann wrote:
On 09/17/2012 12:30 PM, Guillaume GARDET wrote:
For armv5, the compiler does not find the file "bits/c++config.h" whereas the package libstdc++47-devel is installed: ********************************************************************************
[ 531s] In file included from /home/abuild/rpmbuild/BUILD/qt-everywhere-opensource-src-4.8.2/include/QtCore/../../src/corelib/tools/qlist.h:58:0,
[ 531s] from /home/abuild/rpmbuild/BUILD/qt-everywhere-opensource-src-4.8.2/include/QtCore/qlist.h:1,
[ 531s] from /home/abuild/rpmbuild/BUILD/qt-everywhere-opensource-src-4.8.2/include/QtCore/../../src/corelib/tools/qstringlist.h:47,
[ 531s] from /home/abuild/rpmbuild/BUILD/qt-everywhere-opensource-src-4.8.2/include/QtCore/qstringlist.h:1,
[ 531s] from project.h:45, [ 531s] from option.h:45, [ 531s] from property.cpp:43: [ 531s] /usr/armv5el-suse-linux-gnueabi/usr/include/c++/4.7/new:41:28: fatal error: bits/c++config.h: No such file or directory ********************************************************************************
using strace, I found that the file is searched in
/usr/armv5el-suse-linux-gnueabi/usr/include/c++/4.7/bits/c++config.h /usr/armv5el-suse-linux-gnueabi/usr/include/c++/4.7/backward/bits/c++config.h /usr/lib64/gcc/armv5el-suse-linux-gnueabi/4.7/include/bits/c++config.h /usr/armv5el-suse-linux-gnueabi/usr/local/include/bits/c++config.h /usr/lib64/gcc/armv5el-suse-linux-gnueabi/4.7/include-fixed/bits/c++config.h /usr/armv5el-suse-linux-gnueabi/usr/include/bits/c++config.h
but it really is in /usr/include/c++/4.7/armv5tel-suse-linux-gnueabi/bits/c++config.h Is the armv5el / armv5tel difference on purpose? Does anyone have some ideas to solve the problem? There are more packages affected.
I would like to help, but I do not know which package is faulty. IIRC the problem lies in qemu-accel and the fact that we call it armv5tel, but it really is armv5el (no thumb).
Ok. So, we should not enable thumb for armv5? I thought all armv5 have thumb capabilities.
Adrian wanted to switch it to armv5el completely, to get rid of that naming difference.
Or at least make a sym link as a workaround. Guillaume
Alex
Guillaume
Alex
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am Freitag, 5. Oktober 2012, 13:55:34 schrieb Guillaume Gardet:
Le 05/10/2012 12:27, Alexander Graf a écrit :
On 05.10.2012, at 10:49, Guillaume Gardet <guillaume.gardet@free.fr> wrote:
Le 19/09/2012 12:09, Alexander Graf a écrit :
On 19.09.2012, at 12:07, Bernhard M. Wiedemann wrote:
On 09/17/2012 12:30 PM, Guillaume GARDET wrote:
For armv5, the compiler does not find the file "bits/c++config.h" whereas the package libstdc++47-devel is installed: ********************************************************************************
[ 531s] In file included from /home/abuild/rpmbuild/BUILD/qt-everywhere-opensource-src-4.8.2/include/QtCore/../../src/corelib/tools/qlist.h:58:0,
[ 531s] from /home/abuild/rpmbuild/BUILD/qt-everywhere-opensource-src-4.8.2/include/QtCore/qlist.h:1,
[ 531s] from /home/abuild/rpmbuild/BUILD/qt-everywhere-opensource-src-4.8.2/include/QtCore/../../src/corelib/tools/qstringlist.h:47,
[ 531s] from /home/abuild/rpmbuild/BUILD/qt-everywhere-opensource-src-4.8.2/include/QtCore/qstringlist.h:1,
[ 531s] from project.h:45, [ 531s] from option.h:45, [ 531s] from property.cpp:43: [ 531s] /usr/armv5el-suse-linux-gnueabi/usr/include/c++/4.7/new:41:28: fatal error: bits/c++config.h: No such file or directory ********************************************************************************
using strace, I found that the file is searched in
/usr/armv5el-suse-linux-gnueabi/usr/include/c++/4.7/bits/c++config.h /usr/armv5el-suse-linux-gnueabi/usr/include/c++/4.7/backward/bits/c++config.h /usr/lib64/gcc/armv5el-suse-linux-gnueabi/4.7/include/bits/c++config.h /usr/armv5el-suse-linux-gnueabi/usr/local/include/bits/c++config.h /usr/lib64/gcc/armv5el-suse-linux-gnueabi/4.7/include-fixed/bits/c++config.h /usr/armv5el-suse-linux-gnueabi/usr/include/bits/c++config.h
but it really is in /usr/include/c++/4.7/armv5tel-suse-linux-gnueabi/bits/c++config.h Is the armv5el / armv5tel difference on purpose? Does anyone have some ideas to solve the problem? There are more packages affected.
I would like to help, but I do not know which package is faulty. IIRC the problem lies in qemu-accel and the fact that we call it armv5tel, but it really is armv5el (no thumb).
Ok.
So, we should not enable thumb for armv5? I thought all armv5 have thumb capabilities.
Maybe, but we faced problems with thumb support. So, yes, armv5 should not use thumb.
Adrian wanted to switch it to armv5el completely, to get rid of that naming difference.
Or at least make a sym link as a workaround.
We have currently a broken rpm package on armv5, I bootstrap i currently manually. Afterwards we need to do a clean rebuild, so please do not add workarounds until we tried that. I hope it solves the problem. -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 05/10/2012 14:45, Adrian Schröter a écrit :
Am Freitag, 5. Oktober 2012, 13:55:34 schrieb Guillaume Gardet:
Le 05/10/2012 12:27, Alexander Graf a écrit :
On 05.10.2012, at 10:49, Guillaume Gardet <guillaume.gardet@free.fr> wrote:
Le 19/09/2012 12:09, Alexander Graf a écrit :
On 19.09.2012, at 12:07, Bernhard M. Wiedemann wrote:
On 09/17/2012 12:30 PM, Guillaume GARDET wrote:
> For armv5, the compiler does not find the file "bits/c++config.h" > whereas the package libstdc++47-devel is installed: > ******************************************************************************** > > [ 531s] In file included from > /home/abuild/rpmbuild/BUILD/qt-everywhere-opensource-src-4.8.2/include/QtCore/../../src/corelib/tools/qlist.h:58:0, > > [ 531s] from > /home/abuild/rpmbuild/BUILD/qt-everywhere-opensource-src-4.8.2/include/QtCore/qlist.h:1, > > [ 531s] from > /home/abuild/rpmbuild/BUILD/qt-everywhere-opensource-src-4.8.2/include/QtCore/../../src/corelib/tools/qstringlist.h:47, > > [ 531s] from > /home/abuild/rpmbuild/BUILD/qt-everywhere-opensource-src-4.8.2/include/QtCore/qstringlist.h:1, > > [ 531s] from project.h:45, > [ 531s] from option.h:45, > [ 531s] from property.cpp:43: > [ 531s] /usr/armv5el-suse-linux-gnueabi/usr/include/c++/4.7/new:41:28: > fatal error: bits/c++config.h: No such file or directory > ******************************************************************************** > using strace, I found that the file is searched in
/usr/armv5el-suse-linux-gnueabi/usr/include/c++/4.7/bits/c++config.h /usr/armv5el-suse-linux-gnueabi/usr/include/c++/4.7/backward/bits/c++config.h /usr/lib64/gcc/armv5el-suse-linux-gnueabi/4.7/include/bits/c++config.h /usr/armv5el-suse-linux-gnueabi/usr/local/include/bits/c++config.h /usr/lib64/gcc/armv5el-suse-linux-gnueabi/4.7/include-fixed/bits/c++config.h /usr/armv5el-suse-linux-gnueabi/usr/include/bits/c++config.h
but it really is in /usr/include/c++/4.7/armv5tel-suse-linux-gnueabi/bits/c++config.h Is the armv5el / armv5tel difference on purpose? Does anyone have some ideas to solve the problem? There are more packages affected.
I would like to help, but I do not know which package is faulty. IIRC the problem lies in qemu-accel and the fact that we call it armv5tel, but it really is armv5el (no thumb). Ok.
So, we should not enable thumb for armv5? I thought all armv5 have thumb capabilities. Maybe, but we faced problems with thumb support.
So, yes, armv5 should not use thumb.
Ok.
Adrian wanted to switch it to armv5el completely, to get rid of that naming difference. Or at least make a sym link as a workaround. We have currently a broken rpm package on armv5, I bootstrap i currently manually. Afterwards we need to do a clean rebuild, so please do not add workarounds until we tried that.
I hope it solves the problem.
Ok. Ping us when it can be tested. Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am Freitag, 5. Oktober 2012, 14:57:16 schrieb Guillaume Gardet: ...
Adrian wanted to switch it to armv5el completely, to get rid of that naming difference. Or at least make a sym link as a workaround. We have currently a broken rpm package on armv5, I bootstrap i currently manually. Afterwards we need to do a clean rebuild, so please do not add workarounds until we tried that.
I hope it solves the problem.
Ok. Ping us when it can be tested.
checking this again, using armv5 without thumb would make us quite special. Debian and Fedora are using both thumb. And ubuntu gave up on v5 at all. So, I really wonder if the decision to not use thumb on v5 is really the right one or if we should revisit this. -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 05.10.2012, at 15:20, Adrian Schröter wrote:
Am Freitag, 5. Oktober 2012, 14:57:16 schrieb Guillaume Gardet: ...
Adrian wanted to switch it to armv5el completely, to get rid of that naming difference. Or at least make a sym link as a workaround. We have currently a broken rpm package on armv5, I bootstrap i currently manually. Afterwards we need to do a clean rebuild, so please do not add workarounds until we tried that.
I hope it solves the problem.
Ok. Ping us when it can be tested.
checking this again, using armv5 without thumb would make us quite special. Debian and Fedora are using both thumb. And ubuntu gave up on v5 at all.
So, I really wonder if the decision to not use thumb on v5 is really the right one or if we should revisit this.
I thought thumbv1 (which is what armv5 does) is slower than arm code? Do they actually compile code for thumb? Or do they just say it's tel but run arm code? Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 5 October 2012 14:20, Adrian Schröter <adrian@suse.de> wrote:
Am Freitag, 5. Oktober 2012, 14:57:16 schrieb Guillaume Gardet: ...
Adrian wanted to switch it to armv5el completely, to get rid of that naming difference. Or at least make a sym link as a workaround. We have currently a broken rpm package on armv5, I bootstrap i currently manually. Afterwards we need to do a clean rebuild, so please do not add workarounds until we tried that.
I hope it solves the problem.
Ok. Ping us when it can be tested.
checking this again, using armv5 without thumb would make us quite special. Debian and Fedora are using both thumb. And ubuntu gave up on v5 at all.
So, I really wonder if the decision to not use thumb on v5 is really the right one or if we should revisit this.
I would say we most certainly DO WANT thumb support. IIRC all v5 implementations have thumb so regardless of what hardware one would use it on it would work. We should avoid doing something different to the others especially as it wouldn't make us better but actually worse. Saying that v5 shouldn't consume cycles if there are issues on v7. -- Andrew Wafaa IRC: FunkyPenguin GPG: 0x3A36312F -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am Freitag, 5. Oktober 2012, 14:27:19 schrieb Andrew Wafaa:
On 5 October 2012 14:20, Adrian Schröter <adrian@suse.de> wrote:
Am Freitag, 5. Oktober 2012, 14:57:16 schrieb Guillaume Gardet: ...
Adrian wanted to switch it to armv5el completely, to get rid of that naming difference. Or at least make a sym link as a workaround. We have currently a broken rpm package on armv5, I bootstrap i currently manually. Afterwards we need to do a clean rebuild, so please do not add workarounds until we tried that.
I hope it solves the problem.
Ok. Ping us when it can be tested.
checking this again, using armv5 without thumb would make us quite special. Debian and Fedora are using both thumb. And ubuntu gave up on v5 at all.
So, I really wonder if the decision to not use thumb on v5 is really the right one or if we should revisit this.
I would say we most certainly DO WANT thumb support. IIRC all v5 implementations have thumb so regardless of what hardware one would use it on it would work. We should avoid doing something different to the others especially as it wouldn't make us better but actually worse. Saying that v5 shouldn't consume cycles if there are issues on v7.
Do we have the agreement that we want to enable thumb in factory for v5 and v7 to look where the problems are? It was the java stack on v7, I have no idea what it was on v5. But in any case, we want to solve them? adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 08.10.2012, at 11:07, Adrian Schröter wrote:
Am Freitag, 5. Oktober 2012, 14:27:19 schrieb Andrew Wafaa:
On 5 October 2012 14:20, Adrian Schröter <adrian@suse.de> wrote:
Am Freitag, 5. Oktober 2012, 14:57:16 schrieb Guillaume Gardet: ...
> Adrian wanted to switch it to armv5el completely, to get rid of that naming difference. Or at least make a sym link as a workaround. We have currently a broken rpm package on armv5, I bootstrap i currently manually. Afterwards we need to do a clean rebuild, so please do not add workarounds until we tried that.
I hope it solves the problem.
Ok. Ping us when it can be tested.
checking this again, using armv5 without thumb would make us quite special. Debian and Fedora are using both thumb. And ubuntu gave up on v5 at all.
So, I really wonder if the decision to not use thumb on v5 is really the right one or if we should revisit this.
I would say we most certainly DO WANT thumb support. IIRC all v5 implementations have thumb so regardless of what hardware one would use it on it would work. We should avoid doing something different to the others especially as it wouldn't make us better but actually worse. Saying that v5 shouldn't consume cycles if there are issues on v7.
Do we have the agreement that we want to enable thumb in factory for v5 and v7 to look where the problems are?
It was the java stack on v7, I have no idea what it was on v5.
But in any case, we want to solve them?
Good question. How about we enable thumb for v7, but leave it off for gcj? That way we work around the broken Java issue, but still get all the fancy thumb'ness. For thumb-1, which is what v5 uses, all benchmarks I've seen so far showed slowdowns from using it, so I wouldn't recommend enabling it. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 08/10/2012 11:09, Alexander Graf a écrit :
On 08.10.2012, at 11:07, Adrian Schröter wrote:
Am Freitag, 5. Oktober 2012, 14:27:19 schrieb Andrew Wafaa:
On 5 October 2012 14:20, Adrian Schröter <adrian@suse.de> wrote:
Am Freitag, 5. Oktober 2012, 14:57:16 schrieb Guillaume Gardet: ...
>> Adrian wanted to switch it to armv5el completely, to get rid of that naming difference. > Or at least make a sym link as a workaround. We have currently a broken rpm package on armv5, I bootstrap i currently manually. Afterwards we need to do a clean rebuild, so please do not add workarounds until we tried that.
I hope it solves the problem.
Ok. Ping us when it can be tested. checking this again, using armv5 without thumb would make us quite special. Debian and Fedora are using both thumb. And ubuntu gave up on v5 at all.
So, I really wonder if the decision to not use thumb on v5 is really the right one or if we should revisit this.
I would say we most certainly DO WANT thumb support. IIRC all v5 implementations have thumb so regardless of what hardware one would use it on it would work. We should avoid doing something different to the others especially as it wouldn't make us better but actually worse. Saying that v5 shouldn't consume cycles if there are issues on v7. Do we have the agreement that we want to enable thumb in factory for v5 and v7 to look where the problems are?
It was the java stack on v7, I have no idea what it was on v5.
But in any case, we want to solve them? Good question. How about we enable thumb for v7, but leave it off for gcj? That way we work around the broken Java issue, but still get all the fancy thumb'ness.
I think it is a good idea.
For thumb-1, which is what v5 uses, all benchmarks I've seen so far showed slowdowns from using it, so I wouldn't recommend enabling it.
Yes. We just save space since compiled code is smaller. So, I would not enable it. Guillaume
Alex
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am Montag, 8. Oktober 2012, 11:30:24 schrieb Guillaume Gardet:
Le 08/10/2012 11:09, Alexander Graf a écrit :
On 08.10.2012, at 11:07, Adrian Schröter wrote:
Am Freitag, 5. Oktober 2012, 14:27:19 schrieb Andrew Wafaa:
On 5 October 2012 14:20, Adrian Schröter <adrian@suse.de> wrote:
Am Freitag, 5. Oktober 2012, 14:57:16 schrieb Guillaume Gardet: ...
>>> Adrian wanted to switch it to armv5el completely, to get rid of that naming difference. >> Or at least make a sym link as a workaround. > We have currently a broken rpm package on armv5, I bootstrap i currently manually. > Afterwards we need to do a clean rebuild, so please do not add workarounds until > we tried that. > > I hope it solves the problem. > Ok. Ping us when it can be tested. checking this again, using armv5 without thumb would make us quite special. Debian and Fedora are using both thumb. And ubuntu gave up on v5 at all.
So, I really wonder if the decision to not use thumb on v5 is really the right one or if we should revisit this.
I would say we most certainly DO WANT thumb support. IIRC all v5 implementations have thumb so regardless of what hardware one would use it on it would work. We should avoid doing something different to the others especially as it wouldn't make us better but actually worse. Saying that v5 shouldn't consume cycles if there are issues on v7. Do we have the agreement that we want to enable thumb in factory for v5 and v7 to look where the problems are?
It was the java stack on v7, I have no idea what it was on v5.
But in any case, we want to solve them? Good question. How about we enable thumb for v7, but leave it off for gcj? That way we work around the broken Java issue, but still get all the fancy thumb'ness.
I think it is a good idea.
okay
For thumb-1, which is what v5 uses, all benchmarks I've seen so far showed slowdowns from using it, so I wouldn't recommend enabling it.
Yes. We just save space since compiled code is smaller. So, I would not enable it.
However, that means that we use a different default than built-in of gcc and used by other distros. Do you think this speedup is it really worth to become different here? And also the cpu/arch short name does not 5tel as we use it means thumb mode. And we would need to patch a number of packages, including rpm to introduce the armv5el architecture ... -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 08.10.2012, at 11:46, Adrian Schröter wrote:
Am Montag, 8. Oktober 2012, 11:30:24 schrieb Guillaume Gardet:
Le 08/10/2012 11:09, Alexander Graf a écrit :
On 08.10.2012, at 11:07, Adrian Schröter wrote:
Am Freitag, 5. Oktober 2012, 14:27:19 schrieb Andrew Wafaa:
On 5 October 2012 14:20, Adrian Schröter <adrian@suse.de> wrote:
Am Freitag, 5. Oktober 2012, 14:57:16 schrieb Guillaume Gardet: ... >>>> Adrian wanted to switch it to armv5el completely, to get rid of that naming difference. >>> Or at least make a sym link as a workaround. >> We have currently a broken rpm package on armv5, I bootstrap i currently manually. >> Afterwards we need to do a clean rebuild, so please do not add workarounds until >> we tried that. >> >> I hope it solves the problem. >> > Ok. Ping us when it can be tested. checking this again, using armv5 without thumb would make us quite special. Debian and Fedora are using both thumb. And ubuntu gave up on v5 at all.
So, I really wonder if the decision to not use thumb on v5 is really the right one or if we should revisit this.
I would say we most certainly DO WANT thumb support. IIRC all v5 implementations have thumb so regardless of what hardware one would use it on it would work. We should avoid doing something different to the others especially as it wouldn't make us better but actually worse. Saying that v5 shouldn't consume cycles if there are issues on v7. Do we have the agreement that we want to enable thumb in factory for v5 and v7 to look where the problems are?
It was the java stack on v7, I have no idea what it was on v5.
But in any case, we want to solve them? Good question. How about we enable thumb for v7, but leave it off for gcj? That way we work around the broken Java issue, but still get all the fancy thumb'ness.
I think it is a good idea.
okay
For thumb-1, which is what v5 uses, all benchmarks I've seen so far showed slowdowns from using it, so I wouldn't recommend enabling it.
Yes. We just save space since compiled code is smaller. So, I would not enable it.
However, that means that we use a different default than built-in of gcc and used by other distros. Do you think this speedup is it really worth to become different here?
Are you sure? Please double-check. I very much doubt that anyone else builds thumb-1 code.
And also the cpu/arch short name does not 5tel as we use it means thumb mode. And we would need to patch a number of packages, including rpm to introduce the armv5el architecture ...
We can call it armv5tel and compile ARM mode code, no? IIUC that's what the other distros do. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am Montag, 8. Oktober 2012, 11:49:35 schrieb Alexander Graf:
On 08.10.2012, at 11:46, Adrian Schröter wrote:
Am Montag, 8. Oktober 2012, 11:30:24 schrieb Guillaume Gardet:
Le 08/10/2012 11:09, Alexander Graf a écrit :
On 08.10.2012, at 11:07, Adrian Schröter wrote:
Am Freitag, 5. Oktober 2012, 14:27:19 schrieb Andrew Wafaa:
On 5 October 2012 14:20, Adrian Schröter <adrian@suse.de> wrote: > Am Freitag, 5. Oktober 2012, 14:57:16 schrieb Guillaume Gardet: > ... >>>>> Adrian wanted to switch it to armv5el completely, to get rid of that naming difference. >>>> Or at least make a sym link as a workaround. >>> We have currently a broken rpm package on armv5, I bootstrap i currently manually. >>> Afterwards we need to do a clean rebuild, so please do not add workarounds until >>> we tried that. >>> >>> I hope it solves the problem. >>> >> Ok. Ping us when it can be tested. > checking this again, using armv5 without thumb would make us quite special. Debian > and Fedora are using both thumb. And ubuntu gave up on v5 at all. > > So, I really wonder if the decision to not use thumb on v5 is really the right one > or if we should revisit this. > I would say we most certainly DO WANT thumb support. IIRC all v5 implementations have thumb so regardless of what hardware one would use it on it would work. We should avoid doing something different to the others especially as it wouldn't make us better but actually worse. Saying that v5 shouldn't consume cycles if there are issues on v7. Do we have the agreement that we want to enable thumb in factory for v5 and v7 to look where the problems are?
It was the java stack on v7, I have no idea what it was on v5.
But in any case, we want to solve them? Good question. How about we enable thumb for v7, but leave it off for gcj? That way we work around the broken Java issue, but still get all the fancy thumb'ness.
I think it is a good idea.
okay
For thumb-1, which is what v5 uses, all benchmarks I've seen so far showed slowdowns from using it, so I wouldn't recommend enabling it.
Yes. We just save space since compiled code is smaller. So, I would not enable it.
However, that means that we use a different default than built-in of gcc and used by other distros. Do you think this speedup is it really worth to become different here?
Are you sure? Please double-check. I very much doubt that anyone else builds thumb-1 code.
Okay, you are right, they don't use it. However they also do not explicit set --with-mode=arm So, the assumption that the t in armv5tel is for thumb mode is wrong? Anyone knows what it means exactly?
And also the cpu/arch short name does not 5tel as we use it means thumb mode. And we would need to patch a number of packages, including rpm to introduce the armv5el architecture ...
We can call it armv5tel and compile ARM mode code, no? IIUC that's what the other distros do.
Seems so. So we may should rename the OBS scheduler architecture to armv5tel for completeness, but that is cosmetic. And I would like to know what the t means for officially. So, we just need to switch armv7 thumb on now in gcc by using --with-mode=thumb configure switch again. And disable it explicit for libgcj47 build. Right? thanks adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 08.10.2012, at 13:22, Adrian Schröter wrote:
Am Montag, 8. Oktober 2012, 11:49:35 schrieb Alexander Graf:
On 08.10.2012, at 11:46, Adrian Schröter wrote:
Am Montag, 8. Oktober 2012, 11:30:24 schrieb Guillaume Gardet:
Le 08/10/2012 11:09, Alexander Graf a écrit :
On 08.10.2012, at 11:07, Adrian Schröter wrote:
Am Freitag, 5. Oktober 2012, 14:27:19 schrieb Andrew Wafaa: > On 5 October 2012 14:20, Adrian Schröter <adrian@suse.de> wrote: >> Am Freitag, 5. Oktober 2012, 14:57:16 schrieb Guillaume Gardet: >> ... >>>>>> Adrian wanted to switch it to armv5el completely, to get rid of that naming difference. >>>>> Or at least make a sym link as a workaround. >>>> We have currently a broken rpm package on armv5, I bootstrap i currently manually. >>>> Afterwards we need to do a clean rebuild, so please do not add workarounds until >>>> we tried that. >>>> >>>> I hope it solves the problem. >>>> >>> Ok. Ping us when it can be tested. >> checking this again, using armv5 without thumb would make us quite special. Debian >> and Fedora are using both thumb. And ubuntu gave up on v5 at all. >> >> So, I really wonder if the decision to not use thumb on v5 is really the right one >> or if we should revisit this. >> > I would say we most certainly DO WANT thumb support. IIRC all v5 > implementations have thumb so regardless of what hardware one would > use it on it would work. We should avoid doing something different to > the others especially as it wouldn't make us better but actually > worse. Saying that v5 shouldn't consume cycles if there are issues on > v7. Do we have the agreement that we want to enable thumb in factory for v5 and v7 to look where the problems are?
It was the java stack on v7, I have no idea what it was on v5.
But in any case, we want to solve them? Good question. How about we enable thumb for v7, but leave it off for gcj? That way we work around the broken Java issue, but still get all the fancy thumb'ness.
I think it is a good idea.
okay
For thumb-1, which is what v5 uses, all benchmarks I've seen so far showed slowdowns from using it, so I wouldn't recommend enabling it.
Yes. We just save space since compiled code is smaller. So, I would not enable it.
However, that means that we use a different default than built-in of gcc and used by other distros. Do you think this speedup is it really worth to become different here?
Are you sure? Please double-check. I very much doubt that anyone else builds thumb-1 code.
Okay, you are right, they don't use it. However they also do not explicit set --with-mode=arm
So, the assumption that the t in armv5tel is for thumb mode is wrong? Anyone knows what it means exactly?
And also the cpu/arch short name does not 5tel as we use it means thumb mode. And we would need to patch a number of packages, including rpm to introduce the armv5el architecture ...
We can call it armv5tel and compile ARM mode code, no? IIUC that's what the other distros do.
Seems so. So we may should rename the OBS scheduler architecture to armv5tel for completeness, but that is cosmetic. And I would like to know what the t means for officially.
So, we just need to switch armv7 thumb on now in gcc by using
--with-mode=thumb
configure switch again. And disable it explicit for libgcj47 build. Right?
Yup :) Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am Montag, 8. Oktober 2012, 13:49:56 schrieb Alexander Graf:
On 08.10.2012, at 13:22, Adrian Schröter wrote:
...
So, we just need to switch armv7 thumb on now in gcc by using
--with-mode=thumb
configure switch again. And disable it explicit for libgcj47 build. Right?
Yup :)
done. Next is to find out about the real reason of the missing header files on armv5 then (and what makes v5 so special). -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 08/10/2012 11:46, Adrian Schröter a écrit :
Am Montag, 8. Oktober 2012, 11:30:24 schrieb Guillaume Gardet:
Le 08/10/2012 11:09, Alexander Graf a écrit :
On 08.10.2012, at 11:07, Adrian Schröter wrote:
Am Freitag, 5. Oktober 2012, 14:27:19 schrieb Andrew Wafaa:
On 5 October 2012 14:20, Adrian Schröter <adrian@suse.de> wrote:
Am Freitag, 5. Oktober 2012, 14:57:16 schrieb Guillaume Gardet: ... >>>> Adrian wanted to switch it to armv5el completely, to get rid of that naming difference. >>> Or at least make a sym link as a workaround. >> We have currently a broken rpm package on armv5, I bootstrap i currently manually. >> Afterwards we need to do a clean rebuild, so please do not add workarounds until >> we tried that. >> >> I hope it solves the problem. >> > Ok. Ping us when it can be tested. checking this again, using armv5 without thumb would make us quite special. Debian and Fedora are using both thumb. And ubuntu gave up on v5 at all.
So, I really wonder if the decision to not use thumb on v5 is really the right one or if we should revisit this.
I would say we most certainly DO WANT thumb support. IIRC all v5 implementations have thumb so regardless of what hardware one would use it on it would work. We should avoid doing something different to the others especially as it wouldn't make us better but actually worse. Saying that v5 shouldn't consume cycles if there are issues on v7. Do we have the agreement that we want to enable thumb in factory for v5 and v7 to look where the problems are?
It was the java stack on v7, I have no idea what it was on v5.
But in any case, we want to solve them? Good question. How about we enable thumb for v7, but leave it off for gcj? That way we work around the broken Java issue, but still get all the fancy thumb'ness. I think it is a good idea. okay
For thumb-1, which is what v5 uses, all benchmarks I've seen so far showed slowdowns from using it, so I wouldn't recommend enabling it. Yes. We just save space since compiled code is smaller. So, I would not enable it. However, that means that we use a different default than built-in of gcc and used by other distros.
That is true. As amrv5 is now quite old, we may just use the sandard to not lose too much time on it and focus on armv7 and later.
Do you think this speedup is it really worth to become different here? And also the cpu/arch short name does not 5tel as we use it means thumb mode. And we would need to patch a number of packages, including rpm to introduce the armv5el architecture ...
Well. We could use 5tel and use thumb to be as other distros. Then, we could disable thumb and force ARM code for some packages which need speed up and/or are buggy in thumb mode. What do you think about it? Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 08/10/2012 11:07, Adrian Schröter a écrit :
Am Freitag, 5. Oktober 2012, 14:27:19 schrieb Andrew Wafaa:
On 5 October 2012 14:20, Adrian Schröter <adrian@suse.de> wrote:
Am Freitag, 5. Oktober 2012, 14:57:16 schrieb Guillaume Gardet: ...
> Adrian wanted to switch it to armv5el completely, to get rid of that naming difference. Or at least make a sym link as a workaround. We have currently a broken rpm package on armv5, I bootstrap i currently manually. Afterwards we need to do a clean rebuild, so please do not add workarounds until we tried that.
I hope it solves the problem.
Ok. Ping us when it can be tested. checking this again, using armv5 without thumb would make us quite special. Debian and Fedora are using both thumb. And ubuntu gave up on v5 at all.
So, I really wonder if the decision to not use thumb on v5 is really the right one or if we should revisit this.
I would say we most certainly DO WANT thumb support. IIRC all v5 implementations have thumb so regardless of what hardware one would use it on it would work. We should avoid doing something different to the others especially as it wouldn't make us better but actually worse. Saying that v5 shouldn't consume cycles if there are issues on v7. Do we have the agreement that we want to enable thumb in factory for v5 and v7 to look where the problems are?
It was the java stack on v7, I have no idea what it was on v5.
But in any case, we want to solve them?
For armv5 it seems thumb should be slower than ARM code but code size is smaller. So, maybe do not enable for armv5. Armv7 supports thumb and also thumb2. Thumb-2 should be smaller than ARM code and it should be as fast as ARM code. It seems if we use those flags : "-mthumb -march=armv7-a" compiler will use thumb2 and not thumb1. We should add some informations on the wiki about which flags are used for building in OBS for ARM. Guillaume
adrian
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (6)
-
Adrian Schröter -
Alexander Graf -
Andrew Wafaa -
Bernhard M. Wiedemann -
Guillaume Gardet -
Guillaume GARDET