[zypp-devel] architecture not detected correctly after glibc/gcc upgrade
Hi, We just updated to glibc 2.13 and gcc 4.6 and zypper is refusing to install anything below i686, changing the config file with arch = i586 seems to resolve the issue and allows package installations. Not sure why that is happening, any hints? Anas-- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Friday 24 June 2011 14:07:30 Anas Nashif wrote:
Hi, We just updated to glibc 2.13 and gcc 4.6 and zypper is refusing to install anything below i686, changing the config file with
arch = i586
seems to resolve the issue and allows package installations. Not sure why that is happening, any hints?
Hard to tell without log. System architecture was detected correctly? grep 'ZConfig.cc.*SystemArchitecture:' /var/log/zypper.log -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres SUSE LINUX Products GmbH, Development, ma@suse.de GF:Jeff Hawn,Jennifer Guild,Felix Imendörffer, HRB16746(AG Nürnberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On 28 Jun 2011, at 08:34, Michael Andres wrote:
On Friday 24 June 2011 14:07:30 Anas Nashif wrote:
Hi, We just updated to glibc 2.13 and gcc 4.6 and zypper is refusing to install anything below i686, changing the config file with
arch = i586
seems to resolve the issue and allows package installations. Not sure why that is happening, any hints?
Hard to tell without log.
Here is a log: http://pastebin.com/sE9mFfe8
System architecture was detected correctly? grep 'ZConfig.cc.*SystemArchitecture:' /var/log/zypper.log
[root@localhost ~]# grep 'ZConfig.cc.*SystemArchitecture:' /var/log/zypper.log 2011-07-04 05:27:07 <1> localhost(946) [zconfig] ZConfig.cc(ZConfig):569 SystemArchitecture: 'i686' (i686) 2011-07-04 05:28:38 <1> localhost(961) [zconfig] ZConfig.cc(ZConfig):569 SystemArchitecture: 'i686' (i686) anas
--
cu, Michael Andres
+------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres SUSE LINUX Products GmbH, Development, ma@suse.de GF:Jeff Hawn,Jennifer Guild,Felix Imendörffer, HRB16746(AG Nürnberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+
-- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
-- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
I just ran this small test:
#include <iostream>
#include <list>
#include <string>
//
#include "zypp/base/Logger.h"
#include "zypp/Arch.h"
using namespace std;
using namespace zypp;
int main() {
cout << Arch("i686") << "\n";
cout << Arch_noarch.compatibleWith( Arch_i686 ) << "\n";
cout << Arch_i386.compatibleWith( Arch_i686 ) << "\n";
cout << Arch_i486.compatibleWith( Arch_i686 ) << "\n";
cout << Arch_i586.compatibleWith( Arch_i686 ) << "\n";
cout << Arch_i686.compatibleWith( Arch_i686 ) << "\n";
}
and the results are:
bash-3.2# ./arch
i686
0
0
0
0
1
So there is something really bad happening here, not sure what it could be...
Running the same on opensuse 11.4 gives only "1", and no zeros.
Anas
On Mon, Jul 4, 2011 at 12:49 PM, Anas Nashif
On 28 Jun 2011, at 08:34, Michael Andres wrote:
On Friday 24 June 2011 14:07:30 Anas Nashif wrote:
Hi, We just updated to glibc 2.13 and gcc 4.6 and zypper is refusing to install anything below i686, changing the config file with
arch = i586
seems to resolve the issue and allows package installations. Not sure why that is happening, any hints?
Hard to tell without log.
Here is a log:
System architecture was detected correctly? grep 'ZConfig.cc.*SystemArchitecture:' /var/log/zypper.log
[root@localhost ~]# grep 'ZConfig.cc.*SystemArchitecture:' /var/log/zypper.log 2011-07-04 05:27:07 <1> localhost(946) [zconfig] ZConfig.cc(ZConfig):569 SystemArchitecture: 'i686' (i686) 2011-07-04 05:28:38 <1> localhost(961) [zconfig] ZConfig.cc(ZConfig):569 SystemArchitecture: 'i686' (i686)
anas
--
cu, Michael Andres
+------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres SUSE LINUX Products GmbH, Development, ma@suse.de GF:Jeff Hawn,Jennifer Guild,Felix Imendörffer, HRB16746(AG Nürnberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+
-- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
I have got more findings. In Arch.cc the IdString class seems don’t works.
The asSting() method of archs always return empty string, which result in the size of _compatSet is always 1.
Attach is my patch for debug.
With anas’s test case, I have got the follow results:
[root@localhost libzypp]# ./a.out
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
_compatSet.size() is:1
In defCompatibleWith:
_compatSet.size() is:1
i686
0
0
0
0
1
Thanks
Xiaoqiang
From: Nashif, Anas [mailto:anas.nashif@intel.com]
Sent: 2011年7月5日 0:59
To: Michael Andres
Cc: zypp-devel@opensuse.org
Subject: Re: [zypp-devel] architecture not detected correctly after glibc/gcc upgrade
I just ran this small test:
#include <iostream>
#include <list>
#include <string>
//
#include "zypp/base/Logger.h"
#include "zypp/Arch.h"
using namespace std;
using namespace zypp;
int main() {
cout << Arch("i686") << "\n";
cout << Arch_noarch.compatibleWith( Arch_i686 ) << "\n";
cout << Arch_i386.compatibleWith( Arch_i686 ) << "\n";
cout << Arch_i486.compatibleWith( Arch_i686 ) << "\n";
cout << Arch_i586.compatibleWith( Arch_i686 ) << "\n";
cout << Arch_i686.compatibleWith( Arch_i686 ) << "\n";
}
and the results are:
bash-3.2# ./arch
i686
0
0
0
0
1
So there is something really bad happening here, not sure what it could be...
Running the same on opensuse 11.4 gives only "1", and no zeros.
Anas
On Mon, Jul 4, 2011 at 12:49 PM, Anas Nashif
On Friday 24 June 2011 14:07:30 Anas Nashif wrote:
Hi, We just updated to glibc 2.13 and gcc 4.6 and zypper is refusing to install anything below i686, changing the config file with
arch = i586
seems to resolve the issue and allows package installations. Not sure why that is happening, any hints?
Hard to tell without log.
Here is a log: http://pastebin.com/sE9mFfe8
System architecture was detected correctly? grep 'ZConfig.cc.*SystemArchitecture:' /var/log/zypper.log
[root@localhost ~]# grep 'ZConfig.cc.*SystemArchitecture:' /var/log/zypper.log 2011-07-04 05:27:07 <1> localhost(946) [zconfig] ZConfig.cc(ZConfig):569 SystemArchitecture: 'i686' (i686) 2011-07-04 05:28:38 <1> localhost(961) [zconfig] ZConfig.cc(ZConfig):569 SystemArchitecture: 'i686' (i686) anas
--
cu, Michael Andres
+------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres SUSE LINUX Products GmbH, Development, ma@suse.demailto:ma@suse.de GF:Jeff Hawn,Jennifer Guild,Felix Imendörffer, HRB16746(AG Nürnberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+
-- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.orgmailto:zypp-devel%2Bunsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.orgmailto:zypp-devel%2Bhelp@opensuse.org
On Tuesday 05 July 2011 14:47:35 Zhang, Qiang Z wrote:
I have got more findings. In Arch.cc the IdString class seems don’t works.
It requires the sat-pool being initialized, as the pool keeps all the strings.
The asSting() method of archs always return empty string, which result in the size of _compatSet is always 1.
-------
In Arch.cc: in ArchCompatSet ctor (about line 331):
//
defCompatibleWith( _sh4, _noarch );
defCompatibleWith( _sh4a, _noarch,_sh4 );
//
///////////////////////////////////////////////////////////////////
--> // dumpOn( USR ) << endl;
}
Uncomment the dumpOn and the compatsets will be dumped to the zypp logfile
(ZYPP_LOGFILE=- or some filename). Should look like this:
ArchCompatSet:
noarch 0\
________________________________________________________________ 0
i386 2\
______________________________________________________________1_ 2
i486 3\
_____________________________________________________________11_ 6
i586 4\
____________________________________________________________111_ 14
i686 5\
___________________________________________________________1111_ 30
...
x86_64 7\
_________________________________________________________111111_ 126
...
ia64 10\
______________________________________________________1____1111_ 542
s390 11\
_____________________________________________________1__________ 1024
...
In the log check that a line
[zypp::satpool] PoolImpl.cc(PoolImpl):179 Creating sat-pool.
occurs before the
[zypp] Arch.cc(ArchCompatSet):331 ArchCompatSet:
...
-------
Please adapt the meego-dont-use-macro.patch you sent to write out like this:
target.addCompatBit( assertCompatSetEntry( arch0_r )._idBit );
+ MIL << "In defCompatibleWith:" << '('<
SSBrbm93IHRoZSBpc3N1ZSwgdGhlIGdsb2JhbChSZXBvSW5mbzo6bm9SZXBvKSBpbiBSZXBvSW5mby5jYyBhcmUgaW5pdGlhbGl6ZWQgdG9vIGVhcmx5Li4NCg0KSW4gTWVlR28gMS4yIG9yIHN1c2UsIGdsb2JhbHMgaW4gQXJjaC5jYyBhcmUgaW5pdGlhbGl6ZWQgYmVmb3JlIFJlcG9JbmZvLmNjLCB3aGlsZSBpbiBNZWVHbyAxLjMgUmVwb0luZm8uY2MgYXJlIGluaXRpYWxpemVkIGJlZm9yZSBBcmNoLmNjLg0KDQpJbiBSZXBvSW5mby5jYywgdGhlcmUncyBhIGdsb2JhbDoNCiAgIGNvbnN0IFJlcG9JbmZvIFJlcG9JbmZvOjpub1JlcG87DQp0aGlzIHRyaWdnZXIgY2FsbGluZyBBcmNoQ29tcGF0U2V0OjppbnN0YW5jZSgpLCB3aGljaCB3b3VsZCB1c2UgYXJjaCBJZFN0cmluZyBnbG9iYWxzKF9ub2FyY2gsIF9pMzg2LCBldGMpLCB3aGljaCBhcmUgaW5jbHVkZWQgaW4gQXJjaC5jYywgYnV0IHRoZXNlIGdsb2JhbHMgaW4gQXJjaC5jYyBoYXZlIG5vdCBiZWVuIGluaXRpYWxpemVkLg0KDQoNClNvIHRoZSBxdWVzdGlvbiBpcyBob3cgdG8gbGV0IGdvYmFscyBpbiBBcmNoLmNjIGJlaW5nIGluaXRpYWxpemVkIGZpcnN0LCBob3cgdG8gY29udHJvbCB0aGUgaW5pdGlhbGl6YXRpb24gc2VxdWVuY2UuDQoNCg0KVGhhbmtzDQpYaWFvcWlhbmcNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNaWNoYWVsIEFuZHJlcyBbbWFpbHRvOm1hQHN1c2UuZGVdIA0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDA2LCAyMDExIDEyOjA0IEFNDQpUbzogenlwcC1kZXZlbEBvcGVuc3VzZS5vcmcNClN1YmplY3Q6IFJlOiBbenlwcC1kZXZlbF0gYXJjaGl0ZWN0dXJlIG5vdCBkZXRlY3RlZCBjb3JyZWN0bHkgYWZ0ZXIgZ2xpYmMvZ2NjIHVwZ3JhZGUNCg0KT24gVHVlc2RheSAwNSBKdWx5IDIwMTEgMTQ6NDc6MzUgWmhhbmcsIFFpYW5nIFogd3JvdGU6DQo+IEkgaGF2ZSBnb3QgbW9yZSBmaW5kaW5ncy4gSW4gQXJjaC5jYyB0aGUgSWRTdHJpbmcgY2xhc3Mgc2VlbXMgZG9u4oCZdCB3b3Jrcy4NCg0KSXQgcmVxdWlyZXMgdGhlIHNhdC1wb29sIGJlaW5nIGluaXRpYWxpemVkLCBhcyB0aGUgcG9vbCBrZWVwcyBhbGwgdGhlIHN0cmluZ3MuDQoNCj4gVGhlIGFzU3RpbmcoKSBtZXRob2Qgb2YgYXJjaHMgYWx3YXlzIHJldHVybiBlbXB0eSBzdHJpbmcsIHdoaWNoIHJlc3VsdCBpbg0KPiB0aGUgc2l6ZSBvZiBfY29tcGF0U2V0IGlzIGFsd2F5cyAxLg0KDQotLS0tLS0tDQpJbiBBcmNoLmNjOiBpbiBBcmNoQ29tcGF0U2V0IGN0b3IgKGFib3V0IGxpbmUgMzMxKTogDQoNCiAgICAgICAgLy8NCiAgICAgICAgZGVmQ29tcGF0aWJsZVdpdGgoIF9zaDQsCV9ub2FyY2ggKTsNCiAgICAgICAgZGVmQ29tcGF0aWJsZVdpdGgoIF9zaDRhLAlfbm9hcmNoLF9zaDQgKTsNCiAgICAgICAgLy8NCiAgICAgICAgLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLw0KICAtLT4gICAvLyBkdW1wT24oIFVTUiApIDw8IGVuZGw7DQogICAgICB9DQoNClVuY29tbWVudCB0aGUgZHVtcE9uIGFuZCB0aGUgY29tcGF0c2V0cyB3aWxsIGJlIGR1bXBlZCB0byB0aGUgenlwcCBsb2dmaWxlDQooWllQUF9MT0dGSUxFPS0gb3Igc29tZSBmaWxlbmFtZSkuIFNob3VsZCBsb29rIGxpa2UgdGhpczoNCg0KICAgQXJjaENvbXBhdFNldDoNCiAgICBub2FyY2ggICAgICAgICAgIDBcDQogICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIDANCiAgICBpMzg2ICAgICAgICAgICAgIDJcDQogICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzFfIDINCiAgICBpNDg2ICAgICAgICAgICAgIDNcDQogICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fMTFfIDYNCiAgICBpNTg2ICAgICAgICAgICAgIDRcDQogICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18xMTFfIDE0DQogICAgaTY4NiAgICAgICAgICAgICA1XA0KICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18xMTExXyAzMA0KICAgLi4uDQogICAgeDg2XzY0ICAgICAgICAgICA3XA0KICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fMTExMTExXyAxMjYNCiAgIC4uLg0KICAgIGlhNjQgICAgICAgICAgICAxMFwNCiAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzFfX19fMTExMV8gNTQyDQogICAgczM5MCAgICAgICAgICAgIDExXA0KICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18xX19fX19fX19fXyAxMDI0DQogICAuLi4NCg0KSW4gdGhlIGxvZyBjaGVjayB0aGF0IGEgbGluZSANCg0KICBbenlwcDo6c2F0cG9vbF0gUG9vbEltcGwuY2MoUG9vbEltcGwpOjE3OSBDcmVhdGluZyBzYXQtcG9vbC4NCg0Kb2NjdXJzIGJlZm9yZSB0aGUgDQoNCiAgW3p5cHBdIEFyY2guY2MoQXJjaENvbXBhdFNldCk6MzMxIEFyY2hDb21wYXRTZXQ6DQogIC4uLg0KDQoNCi0tLS0tLS0NClBsZWFzZSBhZGFwdCB0aGUgbWVlZ28tZG9udC11c2UtbWFjcm8ucGF0Y2ggeW91IHNlbnQgdG8gd3JpdGUgb3V0IGxpa2UgdGhpczoNCg0KICAgICAgICB0YXJnZXQuYWRkQ29tcGF0Qml0KCBhc3NlcnRDb21wYXRTZXRFbnRyeSggYXJjaDBfciApLl9pZEJpdCApOw0KICArCU1JTCA8PCAiSW4gZGVmQ29tcGF0aWJsZVdpdGg6IiA8PCAnKCc8PHRhcmdldEFyY2hfci5pZCgpIDw8ICcpJw0KICArICAgICAgICAgPDx0YXJnZXRBcmNoX3IgPDwgJzonIDw8IGFyY2gwX3IgPDwgZW5kbDsNCiAgICAjZGVmaW5lIF9TRVRBUkcoTikgaWYgKCBhcmNoIyNOIyNfci5lbXB0eSgpICkgcmV0dXJuOyB0YXJnZXQuYWRkQ29tcGF0Qml0IA0KDQoNCg0KTG9va3MgbGlrZSB0aGUgaW5pdGlhbGlzYXRpb24gb2YgdGhlIGdsb2JhbCBidWlsdGluIGFyY2hpdGVjdHVyZSBzdHJpbmcgdmFsdWVzIA0KZmFpbHMgYW5kIGFsbCB0aGUgSWRTdHJpbmdzIGFyZSBlbXB0eS4gTWF5YmUgdGhlIGdsb2JhbHMgYXJlIGluaXRpYWxpemVkIHRvbyANCmVhcmx5LCBiZWZvcmUgdGhlIHNhdC1wb29sIGlzIHJlYWR5Lg0KCQ0KLS0gDQoNCmN1LA0KICAgIE1pY2hhZWwgQW5kcmVzDQoNCistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQpLZXkgZmluZ2VycHJpbnQgPSAyREZBIDVENzMgMThCMSBFN0VGIEE4NjIgIDI3QUMgM0ZCOCA5RTNBIDI3QzYgQjBFNA0KKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCk1pY2hhZWwgQW5kcmVzICAgU1VTRSBMSU5VWCBQcm9kdWN0cyBHbWJILCBEZXZlbG9wbWVudCwgICBtYUBzdXNlLmRlDQpHRjpKZWZmIEhhd24sSmVubmlmZXIgR3VpbGQsRmVsaXggSW1lbmTDtnJmZmVyLCBIUkIxNjc0NihBRyBOw7xybmJlcmcpIA0KTWF4ZmVsZHN0cmFzc2UgNSwgRC05MDQwOSBOdWVybmJlcmcsIEdlcm1hbnksICsrNDkgKDApOTExIC0gNzQwIDUzLTANCistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCi0tIA0KVG8gdW5zdWJzY3JpYmUsIGUtbWFpbDogenlwcC1kZXZlbCt1bnN1YnNjcmliZUBvcGVuc3VzZS5vcmcNCkZvciBhZGRpdGlvbmFsIGNvbW1hbmRzLCBlLW1haWw6IHp5cHAtZGV2ZWwraGVscEBvcGVuc3VzZS5vcmcNCg0K-- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.orgFor additional commands, e-mail: zypp-devel+help@opensuse.org
SSBhbHNvIGNhbiBjb25maXJtIHRoYXQgdGhlIHNhdC1wb29sIGlzIGluaXRpYWxpemVkIGNvcnJlY3RseS4gV2l0aCBkZWJ1Z2dpbmcgaXQsIFBvb2xRdWVyeUF0dHI6OnJlcG9BdHRyKiBpbiBQb29sUXVlcnkuY2MgaXMgaW5pdGlhbGl6ZWQgYW5kIHNhdC1wb29sIGlzIGNyZWF0ZWQuDQoNClRoZW4gZ2xvYmFsIGluIFJlcG9JbmZvLmNjIGlzIHRyeWluZyB0byBpbml0aWFsaXplZCwgYnV0IGZhaWxzIGFzIGl0IHVzZSBfbm9hcmNoLCBldGMsIHdoaWNoIGhhdmUgbm90IGJlZW4gaW5pdGlhbGl6ZWQuDQoNClRoYW5rcw0KWGlhb3FpYW5nDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFpoYW5nLCBRaWFuZyBaIFttYWlsdG86cWlhbmcuei56aGFuZ0BpbnRlbC5jb21dIA0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDA2LCAyMDExIDI6MjAgUE0NClRvOiBNaWNoYWVsIEFuZHJlczsgenlwcC1kZXZlbEBvcGVuc3VzZS5vcmcNClN1YmplY3Q6IFJFOiBbenlwcC1kZXZlbF0gYXJjaGl0ZWN0dXJlIG5vdCBkZXRlY3RlZCBjb3JyZWN0bHkgYWZ0ZXIgZ2xpYmMvZ2NjIHVwZ3JhZGUNCg0KSSBrbm93IHRoZSBpc3N1ZSwgdGhlIGdsb2JhbChSZXBvSW5mbzo6bm9SZXBvKSBpbiBSZXBvSW5mby5jYyBhcmUgaW5pdGlhbGl6ZWQgdG9vIGVhcmx5Li4NCg0KSW4gTWVlR28gMS4yIG9yIHN1c2UsIGdsb2JhbHMgaW4gQXJjaC5jYyBhcmUgaW5pdGlhbGl6ZWQgYmVmb3JlIFJlcG9JbmZvLmNjLCB3aGlsZSBpbiBNZWVHbyAxLjMgUmVwb0luZm8uY2MgYXJlIGluaXRpYWxpemVkIGJlZm9yZSBBcmNoLmNjLg0KDQpJbiBSZXBvSW5mby5jYywgdGhlcmUncyBhIGdsb2JhbDoNCiAgIGNvbnN0IFJlcG9JbmZvIFJlcG9JbmZvOjpub1JlcG87DQp0aGlzIHRyaWdnZXIgY2FsbGluZyBBcmNoQ29tcGF0U2V0OjppbnN0YW5jZSgpLCB3aGljaCB3b3VsZCB1c2UgYXJjaCBJZFN0cmluZyBnbG9iYWxzKF9ub2FyY2gsIF9pMzg2LCBldGMpLCB3aGljaCBhcmUgaW5jbHVkZWQgaW4gQXJjaC5jYywgYnV0IHRoZXNlIGdsb2JhbHMgaW4gQXJjaC5jYyBoYXZlIG5vdCBiZWVuIGluaXRpYWxpemVkLg0KDQoNClNvIHRoZSBxdWVzdGlvbiBpcyBob3cgdG8gbGV0IGdvYmFscyBpbiBBcmNoLmNjIGJlaW5nIGluaXRpYWxpemVkIGZpcnN0LCBob3cgdG8gY29udHJvbCB0aGUgaW5pdGlhbGl6YXRpb24gc2VxdWVuY2UuDQoNCg0KVGhhbmtzDQpYaWFvcWlhbmcNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNaWNoYWVsIEFuZHJlcyBbbWFpbHRvOm1hQHN1c2UuZGVdIA0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDA2LCAyMDExIDEyOjA0IEFNDQpUbzogenlwcC1kZXZlbEBvcGVuc3VzZS5vcmcNClN1YmplY3Q6IFJlOiBbenlwcC1kZXZlbF0gYXJjaGl0ZWN0dXJlIG5vdCBkZXRlY3RlZCBjb3JyZWN0bHkgYWZ0ZXIgZ2xpYmMvZ2NjIHVwZ3JhZGUNCg0KT24gVHVlc2RheSAwNSBKdWx5IDIwMTEgMTQ6NDc6MzUgWmhhbmcsIFFpYW5nIFogd3JvdGU6DQo+IEkgaGF2ZSBnb3QgbW9yZSBmaW5kaW5ncy4gSW4gQXJjaC5jYyB0aGUgSWRTdHJpbmcgY2xhc3Mgc2VlbXMgZG9u4oCZdCB3b3Jrcy4NCg0KSXQgcmVxdWlyZXMgdGhlIHNhdC1wb29sIGJlaW5nIGluaXRpYWxpemVkLCBhcyB0aGUgcG9vbCBrZWVwcyBhbGwgdGhlIHN0cmluZ3MuDQoNCj4gVGhlIGFzU3RpbmcoKSBtZXRob2Qgb2YgYXJjaHMgYWx3YXlzIHJldHVybiBlbXB0eSBzdHJpbmcsIHdoaWNoIHJlc3VsdCBpbg0KPiB0aGUgc2l6ZSBvZiBfY29tcGF0U2V0IGlzIGFsd2F5cyAxLg0KDQotLS0tLS0tDQpJbiBBcmNoLmNjOiBpbiBBcmNoQ29tcGF0U2V0IGN0b3IgKGFib3V0IGxpbmUgMzMxKTogDQoNCiAgICAgICAgLy8NCiAgICAgICAgZGVmQ29tcGF0aWJsZVdpdGgoIF9zaDQsCV9ub2FyY2ggKTsNCiAgICAgICAgZGVmQ29tcGF0aWJsZVdpdGgoIF9zaDRhLAlfbm9hcmNoLF9zaDQgKTsNCiAgICAgICAgLy8NCiAgICAgICAgLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLw0KICAtLT4gICAvLyBkdW1wT24oIFVTUiApIDw8IGVuZGw7DQogICAgICB9DQoNClVuY29tbWVudCB0aGUgZHVtcE9uIGFuZCB0aGUgY29tcGF0c2V0cyB3aWxsIGJlIGR1bXBlZCB0byB0aGUgenlwcCBsb2dmaWxlDQooWllQUF9MT0dGSUxFPS0gb3Igc29tZSBmaWxlbmFtZSkuIFNob3VsZCBsb29rIGxpa2UgdGhpczoNCg0KICAgQXJjaENvbXBhdFNldDoNCiAgICBub2FyY2ggICAgICAgICAgIDBcDQogICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIDANCiAgICBpMzg2ICAgICAgICAgICAgIDJcDQogICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzFfIDINCiAgICBpNDg2ICAgICAgICAgICAgIDNcDQogICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fMTFfIDYNCiAgICBpNTg2ICAgICAgICAgICAgIDRcDQogICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18xMTFfIDE0DQogICAgaTY4NiAgICAgICAgICAgICA1XA0KICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18xMTExXyAzMA0KICAgLi4uDQogICAgeDg2XzY0ICAgICAgICAgICA3XA0KICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fMTExMTExXyAxMjYNCiAgIC4uLg0KICAgIGlhNjQgICAgICAgICAgICAxMFwNCiAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzFfX19fMTExMV8gNTQyDQogICAgczM5MCAgICAgICAgICAgIDExXA0KICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18xX19fX19fX19fXyAxMDI0DQogICAuLi4NCg0KSW4gdGhlIGxvZyBjaGVjayB0aGF0IGEgbGluZSANCg0KICBbenlwcDo6c2F0cG9vbF0gUG9vbEltcGwuY2MoUG9vbEltcGwpOjE3OSBDcmVhdGluZyBzYXQtcG9vbC4NCg0Kb2NjdXJzIGJlZm9yZSB0aGUgDQoNCiAgW3p5cHBdIEFyY2guY2MoQXJjaENvbXBhdFNldCk6MzMxIEFyY2hDb21wYXRTZXQ6DQogIC4uLg0KDQoNCi0tLS0tLS0NClBsZWFzZSBhZGFwdCB0aGUgbWVlZ28tZG9udC11c2UtbWFjcm8ucGF0Y2ggeW91IHNlbnQgdG8gd3JpdGUgb3V0IGxpa2UgdGhpczoNCg0KICAgICAgICB0YXJnZXQuYWRkQ29tcGF0Qml0KCBhc3NlcnRDb21wYXRTZXRFbnRyeSggYXJjaDBfciApLl9pZEJpdCApOw0KICArCU1JTCA8PCAiSW4gZGVmQ29tcGF0aWJsZVdpdGg6IiA8PCAnKCc8PHRhcmdldEFyY2hfci5pZCgpIDw8ICcpJw0KICArICAgICAgICAgPDx0YXJnZXRBcmNoX3IgPDwgJzonIDw8IGFyY2gwX3IgPDwgZW5kbDsNCiAgICAjZGVmaW5lIF9TRVRBUkcoTikgaWYgKCBhcmNoIyNOIyNfci5lbXB0eSgpICkgcmV0dXJuOyB0YXJnZXQuYWRkQ29tcGF0Qml0IA0KDQoNCg0KTG9va3MgbGlrZSB0aGUgaW5pdGlhbGlzYXRpb24gb2YgdGhlIGdsb2JhbCBidWlsdGluIGFyY2hpdGVjdHVyZSBzdHJpbmcgdmFsdWVzIA0KZmFpbHMgYW5kIGFsbCB0aGUgSWRTdHJpbmdzIGFyZSBlbXB0eS4gTWF5YmUgdGhlIGdsb2JhbHMgYXJlIGluaXRpYWxpemVkIHRvbyANCmVhcmx5LCBiZWZvcmUgdGhlIHNhdC1wb29sIGlzIHJlYWR5Lg0KCQ0KLS0gDQoNCmN1LA0KICAgIE1pY2hhZWwgQW5kcmVzDQoNCistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQpLZXkgZmluZ2VycHJpbnQgPSAyREZBIDVENzMgMThCMSBFN0VGIEE4NjIgIDI3QUMgM0ZCOCA5RTNBIDI3QzYgQjBFNA0KKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCk1pY2hhZWwgQW5kcmVzICAgU1VTRSBMSU5VWCBQcm9kdWN0cyBHbWJILCBEZXZlbG9wbWVudCwgICBtYUBzdXNlLmRlDQpHRjpKZWZmIEhhd24sSmVubmlmZXIgR3VpbGQsRmVsaXggSW1lbmTDtnJmZmVyLCBIUkIxNjc0NihBRyBOw7xybmJlcmcpIA0KTWF4ZmVsZHN0cmFzc2UgNSwgRC05MDQwOSBOdWVybmJlcmcsIEdlcm1hbnksICsrNDkgKDApOTExIC0gNzQwIDUzLTANCistLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCi0tIA0KVG8gdW5zdWJzY3JpYmUsIGUtbWFpbDogenlwcC1kZXZlbCt1bnN1YnNjcmliZUBvcGVuc3VzZS5vcmcNCkZvciBhZGRpdGlvbmFsIGNvbW1hbmRzLCBlLW1haWw6IHp5cHAtZGV2ZWwraGVscEBvcGVuc3VzZS5vcmcNCg0KTu+/ve+/ve+/ve+/ve+/vXLvv73vv7156ZqKXO+/vV7vv73vv71+77+9ey5u77+9K++/ve+/ve+/ve+/ve+/ve+/vceo77+9AWjvv73vv71d77+92Kjvv73vv71c77+9ae+/ve+/ve+/vR7vv73vv73vv73vv70qaXXvv73el++/vV7vv73vv70pensu77+977+9Kw0K-- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.orgFor additional commands, e-mail: zypp-devel+help@opensuse.org
On Wednesday 06 July 2011 08:19:52 Zhang, Qiang Z wrote:
In MeeGo 1.2 or suse, globals in Arch.cc are initialized before RepoInfo.cc, while in MeeGo 1.3 RepoInfo.cc are initialized before Arch.cc.
That's it ;(
So the question is how to let gobals in Arch.cc being initialized first, how to control the initialization sequence.
We currently depend on the linker, and it might be the policy changed with 4.6, that's why it broke. I'll see how to fix his. For now you may try this: Look into the zypp/CMakeLists.txt. You'll find the ADD_LIBRARY line. Reverse the input list of sources: + list( REVERSE zypp_lib_SRCS ) ADD_LIBRARY(zypp SHARED ${zypp_lib_SRCS}) The same change on MeeGo 1.2 or suse will trigger the bug. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres SUSE LINUX Products GmbH, Development, ma@suse.de GF:Jeff Hawn,Jennifer Guild,Felix Imendörffer, HRB16746(AG Nürnberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Yes, I can confirm this solves the problem. Maybe we need to add a few
testcases to catch this issue, similar to my testcase with
Arch_i586.compatibleWith( Arch_i686 )
Thanks,
Anas
On Wed, Jul 6, 2011 at 9:09 AM, Michael Andres
On Wednesday 06 July 2011 08:19:52 Zhang, Qiang Z wrote:
In MeeGo 1.2 or suse, globals in Arch.cc are initialized before RepoInfo.cc, while in MeeGo 1.3 RepoInfo.cc are initialized before Arch.cc.
That's it ;(
So the question is how to let gobals in Arch.cc being initialized first, how to control the initialization sequence.
We currently depend on the linker, and it might be the policy changed with 4.6, that's why it broke. I'll see how to fix his.
For now you may try this: Look into the zypp/CMakeLists.txt. You'll find the ADD_LIBRARY line. Reverse the input list of sources:
+ list( REVERSE zypp_lib_SRCS ) ADD_LIBRARY(zypp SHARED ${zypp_lib_SRCS})
The same change on MeeGo 1.2 or suse will trigger the bug.
--
cu, Michael Andres
+------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres SUSE LINUX Products GmbH, Development, ma@suse.de GF:Jeff Hawn,Jennifer Guild,Felix Imendörffer, HRB16746(AG Nürnberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+
-- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Great, let me have a try now.
From: Nashif, Anas [mailto:anas.nashif@intel.com]
Sent: Wednesday, July 06, 2011 4:22 PM
To: Michael Andres
Cc: zypp-devel@opensuse.org
Subject: Re: [zypp-devel] architecture not detected correctly after glibc/gcc upgrade
Yes, I can confirm this solves the problem. Maybe we need to add a few testcases to catch this issue, similar to my testcase with
Arch_i586.compatibleWith( Arch_i686 )
Thanks,
Anas
On Wed, Jul 6, 2011 at 9:09 AM, Michael Andres
In MeeGo 1.2 or suse, globals in Arch.cc are initialized before RepoInfo.cc, while in MeeGo 1.3 RepoInfo.cc are initialized before Arch.cc. That's it ;(
So the question is how to let gobals in Arch.cc being initialized first, how to control the initialization sequence. We currently depend on the linker, and it might be the policy changed with 4.6, that's why it broke. I'll see how to fix his.
For now you may try this: Look into the zypp/CMakeLists.txt. You'll find the ADD_LIBRARY line. Reverse the input list of sources: + list( REVERSE zypp_lib_SRCS ) ADD_LIBRARY(zypp SHARED ${zypp_lib_SRCS}) The same change on MeeGo 1.2 or suse will trigger the bug. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres SUSE LINUX Products GmbH, Development, ma@suse.demailto:ma@suse.de GF:Jeff Hawn,Jennifer Guild,Felix Imendörffer, HRB16746(AG Nürnberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.orgmailto:zypp-devel%2Bunsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.orgmailto:zypp-devel%2Bhelp@opensuse.org
participants (5)
-
Anas Nashif -
Anas Nashif -
Michael Andres -
Nashif, Anas
-
Zhang, Qiang Z