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

Le 05/10/2012 12:27, Alexander Graf a écrit :

On 05.10.2012, at 10:49, Guillaume Gardet 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

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 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

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

Am Freitag, 5. Oktober 2012, 14:27:19 schrieb Andrew Wafaa:

On 5 October 2012 14: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 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

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 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

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 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

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 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

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 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