On Monday, November 27, 2017 12:48:05 PM CET Andreas Schwab wrote:

On Nov 27 2017, Matthias Brugger wrote:

...

I tried to do another zypper dup from the command line, in case something didn't get updated correctly, but to my supprise I found my self with the next error: zypper: symbol lookup error: /usr/lib64/librpoxy.so.1: undefined symbol: _ZN9libmodman14module_manager8load_dirENSt7__cxx1112basic_stringIcSt11char _traitslcESaIcEEEb That doesn't appear to be a valid mangled symbol, it isn't recognized by c++filt. Probably libproxy needs to be rebuilt.

If the symbol line has as many typos as the other parts of the mail (librpoxy ...) this is to be expected. Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019

On Mon, 2017-11-27 at 14:22 +0100, Jan Engelhardt wrote:

On Monday 2017-11-27 12:48, Andreas Schwab wrote:

...

On Nov 27 2017, Matthias Brugger wrote:

...

I tried to do another zypper dup from the command line, in case something didn't get updated correctly, but to my supprise I found my self with the next error: zypper: symbol lookup error: /usr/lib64/librpoxy.so.1: undefined symbol: _ZN9libmodman14module_manager8load_dirENSt7__cxx1112basic_stringI cSt11char_traitslcESaIcEEEb

That doesn't appear to be a valid mangled symbol, it isn't recognized by c++filt. Probably libproxy needs to be rebuilt.

The symbol and filenames were not properly transcribed into the email. (Or when did you have a "rpoxy.so" in the system?)

-_ZN9libmodman14module_manager8load_dirENSt7__cxx1112basic_stringIcSt 11char_traitslcESaIcEEEb +_ZN9libmodman14module_manager8load_dirINSt7__cxx1112basic_stringIcSt 11char_traitsIcESaIcEEEEEvT_b

Given this is a template, it is conceivable that libmodman changed from explicitly instantiating the template to implicit instantiation with the definition being inlined, i.e. the function moved to a .h file)

modman shouldn't have done that without bumping the SONUM.

THere were no changes to libmodman since 2014 The last rebuild of libmodman was on Jul 17 2017 Libproxy was last rebuilt on 13 Sep 2017 Now somebody explain how this could possibly have gone 'broken' in yesterday's snapshot? The binaries of neither libproxy1 nor libmodman1 have been replaced in > 2 months. Cheers Dominique

On Monday 2017-11-27 14:52, Andreas Schwab wrote:

On Nov 27 2017, Dominique Leuenberger / DimStar wrote:

...

Now somebody explain how this could possibly have gone 'broken' in yesterday's snapshot? The binaries of neither libproxy1 nor libmodman1 have been replaced in > 2 months.

Now it looks more likely like a disk corruption.

Apart from a totally messed-up environment (like LD_LIBRARY_PATH pointing to some very obscure copy of libmodman), I'd concur. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Nov 27 2017, Matthias Brugger wrote:

On 11/27/2017 12:48 PM, Andreas Schwab wrote:

...

On Nov 27 2017, Matthias Brugger wrote:

...

I tried to do another zypper dup from the command line, in case something didn't get updated correctly, but to my supprise I found my self with the next error: zypper: symbol lookup error: /usr/lib64/librpoxy.so.1: undefined symbol: _ZN9libmodman14module_manager8load_dirENSt7__cxx1112basic_stringIcSt11char_traitslcESaIcEEEb

That doesn't appear to be a valid mangled symbol, it isn't recognized by c++filt. Probably libproxy needs to be rebuilt.

I cloned librpoxy [1] to rebuild the package. I'm still getting the same error after installing with rpm -i --nosignature libproxy1-0.4.15-167.1.x86_64.rpm

But I still see the same error.

I cannot reproduce that with a current factory. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El 27-11-2017 a las 15:10, Carl Symons escribió:

On 11/27/2017 03:31 AM, Matthias Brugger wrote:

...

Hi all,

I (distribution) updated today my openSUSE Tumbleweed, but I'm not able to log into the graphical interface.

Last message I see is "[OK] Sttarted Locale Service" screen flickers a few times and then freezes.

I tried to do another zypper dup from the command line, in case something didn't get updated correctly, but to my supprise I found my self with the next error: zypper: symbol lookup error: /usr/lib64/librpoxy.so.1: undefined symbol: _ZN9libmodman14module_manager8load_dirENSt7__cxx1112basic_stringIcSt11char_traitslcESaIcEEEb

Any idea how to debug and fix this?

This is a bug anyway at it should be fixed.. either libproxy has to %require_ge the same libmodman used for build or libmodman has to support symbol visbility.. otherwise it will happen again and again. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Monday 2017-11-27 19:49, Cristian Rodríguez wrote:

El 27-11-2017 a las 15:46, Cristian Rodríguez escribió:

...

This is a bug anyway at it should be fixed.. either libproxy has to %require_ge the same libmodman used for build or libmodman has to support symbol visbility.. otherwise it will happen again and again.

Braino..I mean symbol versioning..

GNOME has a similar problem (bugzilla.opensuse.org/903974 was once opened) and never bothered fixing, so I doubt it will be any different for modman. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Nov 28, 2017 at 6:06 AM, Andreas Schwab wrote:

On Nov 27 2017, Jan Engelhardt wrote:

...

GNOME has a similar problem (bugzilla.opensuse.org/903974 was once opened) and never bothered fixing, so I doubt it will be any different for modman.

It has to be admitted, though, doing proper symbol versioning is easy to get wrong, especially in C++.

Andreas.

On this case, current git of libproxy contains a bundled copy of libmodman.it is actually pretty small, one header and once source file.. and could be used instead on this particular case so it doesn't break the package manager once again.. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 11/28/2017 04:35 AM, Dominique Leuenberger / DimStar wrote:

On Tue, 2017-11-28 at 09:22 -0300, Cristian Rodríguez wrote:

...

On Tue, Nov 28, 2017 at 6:06 AM, Andreas Schwab wrote:

...

On Nov 27 2017, Jan Engelhardt wrote:

...

GNOME has a similar problem (bugzilla.opensuse.org/903974 was once opened) and never bothered fixing, so I doubt it will be any different for modman.

It has to be admitted, though, doing proper symbol versioning is easy to get wrong, especially in C++.

Andreas.

On this case, current git of libproxy contains a bundled copy of libmodman.it is actually pretty small, one header and once source file.. and could be used instead on this particular case so it doesn't break the package manager once again..

Guys, still nobody managed to actually pinpoint what was wrong: neither of the RPMs has had a rebuild for > 2 months.

The 'fix' was even to reinstall the same version of the same package. So there was defintively no rebuild needed.

Can we please stop 'guessing' and get to the point where we are being constructive again? It's tiresome to read the same over and over by different people that did not take the time to read the rest of the thread and understand the issue at hand first.

Thanks Dominique

My message was not a guess. ------------------------- https://forums.opensuse.org/showthread.php/521178-zypper-symbol-lookup-error... installed libmodman1-2.0.1-17.9.x86_64.rpm from the TW repository zypper won't work so sudo rpm -Uvh --force ./libmodman1-2.0.1-17.9.x86_64.rpm ------------------------- The problem raised at forums.opensuse came from someone who had Current and Tumbleweed enabled repositories. The Current repository brought in a higher-numbered, incompatible version of libmodman. In my case, somehow a LEAP 42.3 repository was enabled. (I have no idea how that happened. Probably part of a ymp and I wasn't giving adequate attention to the install.) I downloaded the correct version and installed it with rpm. Then I disabled (it worked) and eventually removed the LEAP 42.3 repository after some research. Something could have been done with priorities and locks, but it wasn't necessary. That there were several people with the same issue makes me think that others had something similar to the forum OP and myself. If this is so, then I don't know how to solve _that_ problem. I don't think that it's possible to add a repository unwittingly. And even if I had known that the LEAP 42.3 repository was being added, I'm not sure that I would (or even know how to) ensure that there were no such conflicts. Whatever the cause, the issue I encountered was operator error, not any of the internal repository issues mentioned.