Bug 285346 – mplayer / schroedinger / liboil fail to compile properly.

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Robert Bradbury 2009-09-17 18:04:41 UTC]

If you specify the "schroedinger" USE option with mplayer it pulls libschroedinge-1.0.so which in turn pulls liboil-0.3.so resulting in the undefined symbol.

Error message is:
/usr/bin/mplayer: symbol lookup error: /usr/lib/libschroedinger-1.0.so.0: undefined symbol: oil_function_class_ptr_avg2_32xn_u8

As it turns out, schroframe.c and schromotion.c call the function oil_avg2_32xn_u8() which is defined in liboilfuncs.h as:
#define oil_avg2_32xn_u8 ((_oil_type_avg2_32xn_u8)(*(void(**)(void))oil_function_class_ptr_avg2_32xn_u8)).

Thus the undefined error.  This is on a Pentium IV Presscot, with debugging (-ggdb).



Reproducible: Always

Steps to Reproduce:
1. USE=schroedinger emerge mplayer
2. mplayer xyzzy.mp3

Actual Results:  
As mentioned a liboil function is undefined.

Expected Results:  
Mplayer (and any other libraries that use libschroedinger) *should* work as distributed.  That presumably means that someone should build and test them with *all* of the flags defined (and all of the sub-libraries included) before they are added to the source tree.

Yea, yea, yea, I know all the "caveats" about what happens if I'm using the "development" version, but a little more effort would prevent errors such as these from sneaking through.

It can probably be fixed by setting mplayer USE flags to -schroedinger but I haven't tested that yet.

[Comment 1 Sebastian Luther (few) 2009-09-17 18:55:20 UTC]

revdep-rebuild doesn't return anything, right? And rebuilding media-libs/schroedinger doesnt help either?

[Comment 2 Sebastian Luther (few) 2009-09-17 18:56:37 UTC]

And emerge --info please.

[Comment 3 Robert Bradbury 2009-09-18 01:03:26 UTC]

Created attachment 204478 [details]
emerge --info and related comments

Attached is emerge --info, mplayer & library versions are appended to the end.

No, revdep doesn't show any problems (as it is designed to show missing libraries, not missing symbols -- at least the way I use it).

And using the -schroedinger USE flag fixes mplayer so that it will play music files without complaining about the undefined symbol.  Note that the libraries and mplayer are compiled for debugging (-ggdb) but I don't think that is the source of the problem.  (I think that the source of the problem is that libschroedinger & liboil are out of sync with each other.)

[Comment 4 Sebastian Luther (few) 2009-09-18 05:49:50 UTC]

(In reply to comment #3)
> (I think that the source of the problem is that
> libschroedinger & liboil are out of sync with each other.)
> 

Right. Did you try to rebuild media-libs/schroedinger? This looks like media-libs/schroedinger was build against an old version of liboil and an update of liboil broke ABI compatibility without changing the library version.

[Comment 5 Robert Bradbury 2009-09-18 07:24:49 UTC]

According to /var/log/emerge.log (and to the best of my memory), when diagnosing this problem, I re-emerged liboil, schroedinger and mplayer.  Still problematic.  I then added "-schroedinger" to /etc/portage/package.use for mplayer and re-emerged it which due to the lack of schroedinger worked ok.

Both dev-libs/liboil and media-libs/schroedinger are flaged ~x86 in /etc/portage/package.keywords so I'm presumably getting the latest versions.

Have you looked in the liboil source to see where the missing symbol is defined?  I could find it in the header file (liboilfuncs.h) in my sources but I couldn't seem to find it in the code sources.  It looks to me like schroedinger is referencing an extinct or 'needs-to-be-defined' symbol in liboil.

[Comment 6 Wormo (RETIRED) 2009-10-05 01:28:32 UTC]

Assigning to schroedinger maintainers, since that seems to be the package at fault.

[Comment 7 Samuli Suominen (RETIRED) 2009-10-05 10:59:28 UTC]

I can't reproduce this with the provided information.

[Comment 8 Mike Hammill 2009-10-08 14:52:24 UTC]

I'm not sure this will help, but I was getting a lot of undefined symbols with similar names to Robert's on ppc32 and was about ready to add to this bug when I thought I'd better compile without ccache and distcc/pump.  To my surprise, this solved the problem for me.

eix liboil
[I] dev-libs/liboil
     Available versions:  (0.3)  0.3.15 (~)0.3.15-r1 0.3.16
	{doc examples test}
     Installed versions:  0.3.16(0.3)(11:43:16 PM 08/22/2009)(examples -doc -test)
     Homepage:            http://liboil.freedesktop.org/
     Description:         library of simple functions that are optimized for various CPUs

eix schroedinger
[I] media-libs/schroedinger
     Available versions:  1.0.5 1.0.7 (~)1.0.7-r2 {gstreamer}
     Installed versions:  1.0.7-r2(04:40:35 PM 10/08/2009)
     Homepage:            http://www.diracvideo.org
     Description:         C-based libraries and GStreamer plugins for the Dirac video codec

Small bit of emerge --info

emerge --info media-libs/schroedinger
Portage 2.1.6.13 (default/linux/powerpc/ppc32/10.0/desktop, gcc-4.3.2, glibc-2.9_p20081201-r2, 2.6.31-gentoo-r1 ppc)
=================================================================
                        System Settings
=================================================================
System uname: Linux-2.6.31-gentoo-r1-ppc-7400,_altivec_supported-with-gentoo-2.0.1
Timestamp of tree: Wed, 07 Oct 2009 23:20:01 +0000
distcc 3.1 powerpc-unknown-linux-gnu [disabled]
ccache version 2.4 [disabled]

[Comment 9 Mike Hammill 2009-11-01 18:14:53 UTC]

I just ran into this same difficulty on x86 (this time upgrading from 1.0.7 to 1.0.8 and again was able to solve it by disabling distcc and setting -j1.  Perhaps this package should be marked incompatible with distcc?

[Comment 10 Samuli Suominen (RETIRED) 2009-11-01 19:15:39 UTC]

(In reply to comment #9)
> Perhaps this package should be marked incompatible with distcc?

There is no such thing as "marking package incompatible with distcc",
while you could do it by adding FEATURES check into a ebuild,
that's not allowed.

[Comment 11 Mike Hammill 2009-11-01 23:27:30 UTC]

> There is no such thing as "marking package incompatible with distcc",
> while you could do it by adding FEATURES check into a ebuild,
> that's not allowed.

I thought I recalled from somewhere in my Gentoo years that the Gentoo team wanted reports of distcc failing where non-distcc building worked.  Obviously, if you can do nothing with this information, I'm sorry to have provided it.   Sad to hear that ebuilds aren't powerful enough to handle this.  Bummer.

[Comment 12 Samuli Suominen (RETIRED) 2009-11-01 23:51:28 UTC]

(In reply to comment #11)
> > There is no such thing as "marking package incompatible with distcc",
> > while you could do it by adding FEATURES check into a ebuild,
> > that's not allowed.
> I thought I recalled from somewhere in my Gentoo years that the Gentoo team
> wanted reports of distcc failing where non-distcc building worked.  Obviously,
> if you can do nothing with this information, I'm sorry to have provided it.  
> Sad to hear that ebuilds aren't powerful enough to handle this.  Bummer.

You misread me. I said there is no way to "mark it incompatible", I never said it isn't a bug and it won't be fixed. Unfortunately I don't have a distcc setup at hand to play around with this... but the bug will stay open until it's properly fixed.

[Comment 13 Robert Bradbury 2009-11-02 19:23:54 UTC]

Pardon me for being uneducated here. But I don't recall "distcc" coming into the equation.  I am running a "straight" x86 system and don't distribute anything (I don't even know the purpose of distcc).

Now, as I reread my bug report, I recall looking at the sources and thought at the  time something like "Hmmm... they are trying to make this 32 bit ((x86) specific and didn't properly provide/test the low level support (e.g. only works on 64 bits)).  But the C declaration is complex and I did not take the time to produce the preprocessor output file.  But the way to attack the problem would be to produce the ".i" file for the problematic sources (for those versed in really old C compilers) and diagnose whether it is a preprocessor error or an actual missing symbol (i.e.either a completely missing 32-bit function or an error someplace in the (preprocessor?) logic in providing such functions.

Now there is presumably a minor probability that its a gcc version problem -- catching those would be worthwhile.

Robert

[Comment 14 Ninan Sajeeth Philip 2010-02-17 11:04:00 UTC]

(In reply to comment #13)
> Pardon me for being uneducated here. But I don't recall "distcc" coming into
> the equation.  I am running a "straight" x86 system and don't distribute
> anything (I don't even know the purpose of distcc).
> 
> Now, as I reread my bug report, I recall looking at the sources and thought at
> the  time something like "Hmmm... they are trying to make this 32 bit ((x86)
> specific and didn't properly provide/test the low level support (e.g. only
> works on 64 bits)).  But the C declaration is complex and I did not take the
> time to produce the preprocessor output file.  But the way to attack the
> problem would be to produce the ".i" file for the problematic sources (for
> those versed in really old C compilers) and diagnose whether it is a
> preprocessor error or an actual missing symbol (i.e.either a completely missing
> 32-bit function or an error someplace in the (preprocessor?) logic in providing
> such functions.
> 
> Now there is presumably a minor probability that its a gcc version problem --
> catching those would be worthwhile.
> 
> Robert
> 

Hi,

I do not know this problem is resolved. But here is something I found that solved the issue for me. I was installing vlc-1.0.2 and my mplayer stopped functioning with the same error. The reason, when I install liboil, it was installing everything to / instead of /usr. When this was corrected, everything came back normal and both vlc and mplayer works perfect.

cheers,
-Sajeeth Philip
[e-mail]

[Comment 15 Alexis Ballier 2011-12-16 14:00:57 UTC]

(In reply to comment #14)
> (In reply to comment #13)
> > Pardon me for being uneducated here. But I don't recall "distcc" coming into
> > the equation.  I am running a "straight" x86 system and don't distribute
> > anything (I don't even know the purpose of distcc).
> > 
> > Now, as I reread my bug report, I recall looking at the sources and thought at
> > the  time something like "Hmmm... they are trying to make this 32 bit ((x86)
> > specific and didn't properly provide/test the low level support (e.g. only
> > works on 64 bits)).  But the C declaration is complex and I did not take the
> > time to produce the preprocessor output file.  But the way to attack the
> > problem would be to produce the ".i" file for the problematic sources (for
> > those versed in really old C compilers) and diagnose whether it is a
> > preprocessor error or an actual missing symbol (i.e.either a completely missing
> > 32-bit function or an error someplace in the (preprocessor?) logic in providing
> > such functions.
> > 
> > Now there is presumably a minor probability that its a gcc version problem --
> > catching those would be worthwhile.
> > 
> > Robert
> > 
> 
> Hi,
> 
> I do not know this problem is resolved. But here is something I found that
> solved the issue for me. I was installing vlc-1.0.2 and my mplayer stopped
> functioning with the same error. The reason, when I install liboil, it was
> installing everything to / instead of /usr. When this was corrected, everything
> came back normal and both vlc and mplayer works perfect.
> 
> cheers,
> -Sajeeth Philip
> [e-mail]

no more comment since then, assuming its fixed, reopen if its not