Description of problem:
The new glibc-* in Fedora 6 (at least on x86_64) prevent vlc to uses mmcpy.
This cause the application to fails to load modules that uses it
Application is completely broken
Version-Release number of selected component (if applicable):
How reproducible: all the time
Steps to Reproduce:
0. run an application that use memcpy (this work fine)
1. update to glibc-*-2.5-18.fc6
2. run an application that use memcpy (for example vlc on x86_64)
this fails with unresolved symbols related to memcpy
3. rebuild vlc against the new glibc fails at runtime
4. revert back to glibc-*-2.5-10.fc6 and new vlc built don't work
5. revert back to glibc-*-2.5-10.fc6 and previous vlc built work fine
memcpy cannot be used at runtime (at least, experienced on x86-64)
This was working fine with previous glibc-*-2.5-10.fc6
Please remove glibc-*-2.5-18.fc6 from the Fedora 6 repository
Rebuild of an applications for using new glibc-*-2.5-18.fc6 do not solve
anything. This produce a broken build, that fails to work at runtime.
Attached a runtime check from vlc that show unresolved symbol related to memcpy
Created attachment 159257 [details]
runtime check when using vlc on Fedora 6 x86_64 unresolved symbols
Ok this is solve by a basic reboot...
Sorry for the noise...
i've lowered priority and severity...
Now the only remaining problems is
Why a reboot is needed ? And why this package need to be updated for FC-6?!
vlc_entry__memcpymmx has nothing to do with glibc memcpy (which hasn't changed
in any way).
The most important question, can you reproduce it again (after downgrading
glibc, perhaps running vlc, then upgrading it again)?
Was vlc running during the glibc upgrade?
Where did you get vlc from (self built, some package repository)?
When it fails to resolve the symbols, can you LD_DEBUG=all it to see where it
was searching and failed to find that symbol?
Which library defines vlc_entry__memcpymmx symbol in vlc?
No feedback, closing.