Mailinglist Archive: zypp-devel (12 mails)

< Previous Next >
RE: [zypp-devel] architecture not detected correctly after glibc/gcc upgrade
I also can confirm that the sat-pool is initialized correctly. With debugging
it, PoolQueryAttr::repoAttr* in is initialized and sat-pool is

Then global in is trying to initialized, but fails as it use
_noarch, etc, which have not been initialized.


-----Original Message-----
From: Zhang, Qiang Z [mailto:qiang.z.zhang@xxxxxxxxx]
Sent: Wednesday, July 06, 2011 2:20 PM
To: Michael Andres; zypp-devel@xxxxxxxxxxxx
Subject: RE: [zypp-devel] architecture not detected correctly after glibc/gcc

I know the issue, the global(RepoInfo::noRepo) in are initialized
too early..

In MeeGo 1.2 or suse, globals in are initialized before,
while in MeeGo 1.3 are initialized before

In, there's a global:
const RepoInfo RepoInfo::noRepo;
this trigger calling ArchCompatSet::instance(), which would use arch IdString
globals(_noarch, _i386, etc), which are included in, but these globals
in have not been initialized.

So the question is how to let gobals in being initialized first, how to
control the initialization sequence.


-----Original Message-----
From: Michael Andres [mailto:ma@xxxxxxx]
Sent: Wednesday, July 06, 2011 12:04 AM
To: zypp-devel@xxxxxxxxxxxx
Subject: Re: [zypp-devel] architecture not detected correctly after glibc/gcc

On Tuesday 05 July 2011 14:47:35 Zhang, Qiang Z wrote:
I have got more findings. In 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 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:

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] Creating sat-pool.

occurs before the

[zypp] 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:" << '('<< << ')'
+ <<targetArch_r << ':' << arch0_r << endl;
#define _SETARG(N) if ( arch##N##_r.empty() ) return; target.addCompatBit

Looks like the initialisation of the global builtin architecture string values
fails and all the IdStrings are empty. Maybe the globals are initialized too
early, before the sat-pool is ready.


Michael Andres

Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4
Michael Andres SUSE LINUX Products GmbH, Development, ma@xxxxxxx
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@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx

< Previous Next >
List Navigation