<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "http://bugs.gentoo.org/bugzilla.dtd">

<bugzilla version="2.22.7"
          urlbase="http://bugs.gentoo.org/"
          maintainer="bugzilla@gentoo.org"
>

    <bug>
          <bug_id>5558</bug_id>
          
          <creation_ts>2002-07-25 08:32 0000</creation_ts>
          <short_desc>smpeg-xmms does not see smpeg includes</short_desc>
          <delta_ts>2003-02-04 19:42:18 0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>Gentoo Linux</product>
          <component>Applications</component>
          <version>1.3</version>
          <rep_platform>x86</rep_platform>
          <op_sys>Linux</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          
          <priority>P3</priority>
          <bug_severity>major</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          
          <everconfirmed>1</everconfirmed>
          <reporter>zhen@gentoo.org</reporter>
          <assigned_to>cardoe@gentoo.org</assigned_to>
          <cc>mkennedy@gentoo.org</cc>

      

      
          <long_desc isprivate="0">
            <who>zhen@gentoo.org</who>
            <bug_when>2002-07-25 08:32:25 0000</bug_when>
            <thetext>This seems to be a trivial issue. When the config for smpeg-xmms is looking for
-lsmpeg, it is not looking in the default includes dir. An smpg-config gives the
full path for the smpeg include. I think that I can handle this one, but I am
not sure where to start. I am guessing the configure script for smpeg-xmms? I
will look around and keep everyone posted.

//John</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>lostlogic@gentoo.org</who>
            <bug_when>2002-07-25 20:36:20 0000</bug_when>
            <thetext>I believe this is a gcc-3.1 error and have seen it before, but do not know the
solution.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>tester@gentoo.org</who>
            <bug_when>2002-08-01 01:14:14 0000</bug_when>
            <thetext>The exact error is:
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.1.1/../../../libsmpeg.so: undefined referen
ce to `operator new[](unsigned)&apos;
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.1.1/../../../libsmpeg.so: undefined referen
ce to `operator delete(void*)&apos;
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.1.1/../../../libsmpeg.so: undefined referen
ce to `operator delete[](void*)&apos;
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.1.1/../../../libsmpeg.so: undefined referen
ce to `operator new(unsigned)&apos;
collect2: ld returned 1 exit status
configure: failed program was:

And smpeg has been compiled with the same compiler (gcc 3.1.1-r1)... now why is
is asking for clearly C++ symbols on a C library.. Is it very bizzare...

Small test case:
gcc test.c -lsmpeg 
on the file:
char SMPEG_new_data();
int main() {
SMPEG_new_data()
; return 0; }

but its a smpeg bug</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>tester@gentoo.org</who>
            <bug_when>2002-08-01 01:17:30 0000</bug_when>
            <thetext>It works when compiled as
g++ -lsmpeg conftest.c
and declaring the function as:
extern &quot;C&quot; char SMPEG_new_data();

smpeg is C++.... compiled with a C interface...</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>tester@gentoo.org</who>
            <bug_when>2002-08-01 01:29:07 0000</bug_when>
            <thetext>Created an attachment (id=2717)
gcc 3.1 fix for smpeg

This is the gcc 3.1 fix from RedHat for smpeg</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>cardoe@gentoo.org</who>
            <bug_when>2002-08-03 04:27:30 0000</bug_when>
            <thetext>New ebuilds in Portage! Please unmask and test! 

smpeg-0.4.4-r3 and smpeg-xmms-0.3.4-r2

Please post which compiler you used! I want some successful tests with gcc-3.1
and gcc-2.95 before unmasking!</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>cardoe@gentoo.org</who>
            <bug_when>2002-08-03 07:55:48 0000</bug_when>
            <thetext>Included a new ebuild of smpeg-xmms-0.3.5 :) Please test. It&apos;s still masked. </thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>bazik@gentoo.org</who>
            <bug_when>2002-08-03 22:58:06 0000</bug_when>
            <thetext>Compiled with Gcc 3.1 and these flags:

CHOST=&quot;i686-pc-linux-gnu&quot;
CFLAGS=&quot;-mcpu=athlon -O3 -pipe -fomit-frame-pointer -mmmx -m3dnow -mno-sse
-mno-sse2&quot;
CXXFLAGS=&quot;-mcpu=athlon -O3 -pipe -fomit-frame-pointer -mmmx -m3dnow -mno-sse
-mno-sse2&quot;


Just watched a 2h DivX movie without problems :)</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>cardoe@gentoo.org</who>
            <bug_when>2002-08-04 05:17:32 0000</bug_when>
            <thetext>Excellent. It was tested on 2 gcc-2.95, 1 gcc-3.1 and 1 gcc-3.2 box and all
confirmed it worked so I think this is going to be an unmask...</thetext>
          </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>2717</attachid>
            <date>2002-08-01 01:29 0000</date>
            <desc>gcc 3.1 fix for smpeg</desc>
            <filename>smpeg-0.4.4-gcc31.patch</filename>
            <type>text/plain</type>
            <data encoding="base64">LS0tIHNtcGVnLTAuNC40L01ha2VmaWxlLmFtLmdjYzMJTW9uIEphbiAgNyAxNzoyMTowMyAyMDAy
CisrKyBzbXBlZy0wLjQuNC9NYWtlZmlsZS5hbQlNb24gSmFuICA3IDE3OjIxOjE3IDIwMDIKQEAg
LTM4LDcgKzM4LDggQEAKIAogbGlic21wZWdfbGFfTElCQUREID0JCVwKIAlhdWRpby9saWJhdWRp
by5sYQlcCi0JdmlkZW8vbGlidmlkZW8ubGEKKwl2aWRlby9saWJ2aWRlby5sYSAgICAgICBcCisg
ICAgICAgIC1sc3VwYysrCiAKIEVYVFJBX0RJU1QgPQkJXAogCUNIQU5HRVMJCVwK
</data>        

          </attachment>
    </bug>

</bugzilla>