Transcode Compilation Issue with libavcodec

illiadum · 11-28-2008, 05:20 PM

Hi all,
So I'm trying to compile transcode-1.0.6 on my SLAMD64 12.1 install. The first couple times I tried to ./configure, I got various missing package errors, including libavcodec.

After installing everything asked for successfully, I tried again. I got something indicating that it could not link libavcodec and that I should install ffmpeg. As it happens, I installed ffmpeg some time ago. OK fine, I went over to the directory in which I still had the ffmpeg code and did:

Code:

./configure --enable-nonfree --enable-gpl --enable-libamr-nb --enable-libamr-wb

And then the standard make & make install. Things went fine. The reason I'm using the nonfree and amr stuff is so that I can encode things from my cellphone into mp3.

OK, so far so good. Did the configure on transcode one more time and things went well. Tried to make transcode and I got:

Code:

/usr/lib64/gcc/x86_64-slamd64-linux/4.1.2/../../../../x86_64-slamd64-linux/bin/ld: /usr/local/lib/libavcodec.a(allcodecs.o): relocation R_X86_64_32 against `aasc_decoder' can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/libavcodec.a: could not read symbols: Bad value
collect2: ld returned 1 exit status

Alright...so I need to recompile something with option "-fPIC". I tried to recompile ffmpeg with this in case that meant the libavcodec...no go. I tried to recompile transcode with this in case it meant transcode itself...no go.

Neither recognizes "-fPIC" as a valid option. My question then is this: What do I need to do in order to get transcode to compile?

If anyone knows of some other easier way that I can get a couple AVIs onto a DVD, that works too. I'm just trying to put together a couple videos for the girlfriend as a little surprise and this library crap is making me crazy.

Anyone know what I'm doing wrong? Much appreciated!

weibullguy · 11-28-2008, 05:49 PM

As you may or may not have ascertained, /usr/local/lib/libavcodec.a is a 32-bit archive and you are trying to build a 64-bit transcode. You need to rebuild ffmpeg as a 64-bit library. I don't know how your tried to pass -fPIC when you rebuilt because you didn't tell us, but -fPIC is a CFLAG, not a configure script option. You would configure ffmpeg for a 64-bit build something like this

Code:

CFLAGS="-m64 -mtune=athlon64 -pipe -fPIC" ./configure --prefix=/usr \
--cc="gcc -m64 -mtune=athlon64 -pipe" \
--{,sh}libdir=/usr/lib64 --enable-shared  \
--enable-pthreads --enable-gpl \
--disable-ffplay --enable-postproc

illiadum · 11-28-2008, 08:22 PM

First off, thanks very much for the reply. You've granted me another piece to the puzzle.

Muliple libraries 32/64 have caused issue for me in the past and generated quite a lot of work. I still don't fully understand everything that goes into this. For example, why I've got /usr/lib, /usr/local/lib and so many other paths to libraries. It seems everything I install wants to put files in a different spot.

So I took the configure line you posted and added the things I need to keep the AMR stuff for continued cellphone to mp3 encoding. I used this to reconfig ffmpeg:

Code:

CFLAGS="-m64 -mtune=athlon64 -pipe -fPIC" ./configure --prefix=/usr --cc="gcc -m64 -mtune=athlon64 -pipe" --{,sh}libdir=/usr/lib64 --enable-shared --enable-pthreads --enable-nonfree --enable-libamr-nb --enable-libamr-wb --enable-gpl --disable-ffplay --enable-postproc

OK, configure goes great. But then, when I try to make I get:

Code:

make                    -C libavutil   all
make[1]: Entering directory `/opt/ffmpeg/ffmpeg/libavutil'
gcc -m64 -mtune=athlon64 -pipe -shared -Wl,-soname,libavutil.so.49  -rdynamic -export-dynamic -Wl,--warn-common -Wl,--as-needed -Wl,-rpath-link,"/opt/ffmpeg/ffmpeg"/libavcodec -Wl,-rpath-link,"/opt/ffmpeg/ffmpeg"/libavformat -Wl,-rpath-link,"/opt/ffmpeg/ffmpeg"/libavutil -Wl,-Bsymbolic -o libavutil.so.49 adler32.o aes.o base64.o crc.o des.o fifo.o intfloat_readwrite.o lls.o log.o lzo.o mathematics.o md5.o mem.o random.o rational.o rc4.o sha1.o string.o tree.o  -lz -pthread -lm -lamrnb -lm -lamrwb -lm   -ldl -ldl
/usr/lib64/gcc/x86_64-slamd64-linux/4.1.2/../../../../x86_64-slamd64-linux/bin/ld: adler32.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
adler32.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[1]: *** [libavutil.so.49] Error 1
make[1]: Leaving directory `/opt/ffmpeg/ffmpeg/libavutil'
make: *** [lib] Error 2

So, just for grins, added the "-fPIC" to CC params in addition to the CFLAGS params.

Wonderful! Everything compiles great. ffmpeg is now reinstalled with above configure options.

Now back to transcode...

Trying just a normal config,make,make install, I get:

Code:

/usr/lib64/gcc/x86_64-slamd64-linux/4.1.2/../../../../x86_64-slamd64-linux/bin/ld: /usr/local/lib/libavcodec.a(allcodecs.o): relocation R_X86_64_32 against `aasc_decoder' can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/libavcodec.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[3]: *** [import_ffmpeg.la] Error 1
make[3]: Leaving directory `/opt/videotrans/transcode-1.0.6/import'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/opt/videotrans/transcode-1.0.6/import'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/opt/videotrans/transcode-1.0.6'
make: *** [all] Error 2

OK, same thing as before. Let me try to put -fPIC into the CC and CFLAGS for configure. A little massaging and configure goes through as follows:

Code:

CFLAGS="-m64 -mtune=athlon64 -pipe -fPIC" CC="gcc -m64 -mtune=athlon64 -pipe -fPIC" ./configure --prefix=/usr --enable-shared --enable-pthreads --disable-ffplay --enable-postproc

Alright. But on make, again I get:

Code:

/usr/lib64/gcc/x86_64-slamd64-linux/4.1.2/../../../../x86_64-slamd64-linux/bin/ld: /usr/local/lib/libavcodec.a(allcodecs.o): relocation R_X86_64_32 against `aasc_decoder' can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/libavcodec.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[3]: *** [import_ffmpeg.la] Error 1
make[3]: Leaving directory `/opt/videotrans/transcode-1.0.6/import'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/opt/videotrans/transcode-1.0.6/import'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/opt/videotrans/transcode-1.0.6'
make: *** [all] Error 2

OK. So I am indeed closer. However, I'm missing something.
I'm just not operating at the level of knowledge that I need to understand what's going on here.

Can anyone clarify further? Again, the input is much appreciated!

weibullguy · 11-29-2008, 01:47 AM

Try this when you configure transcode

Code:

sed -i '/^deflib=/s:/lib:&64:' configure &&
CC="gcc -m64 -mtune=athlon64 -pipe" \
PKG_CONFIG_PATH="/usr/lib64/pkgconfig:/usr/local/lib64/pkgconfig" \
./configure --prefix=/usr --libdir=/usr/lib64

Also, don't use the -mtune=athlong64 unless you have an AMD processor (sorry, I should have mentioned that in my first post). The other option is to delete the 32-bit ffmpeg you have installed in the /usr/local hierarchy.

illiadum · 11-29-2008, 02:18 AM

Beautiful! That did it!

I did get another error complaining about libmpeg2 (which had already been compiled/installed in 32-bit). I did a make uninstall of the old version, ldconfig, downloaded the svn version of libmpeg2 and configured with the same line you provided then installed & one more ldconfig.

After clean, config, make, transcode is finally installed!

Thanks so much for your help, I really appreciate it!

Now, if you or someone else has the time or interest, care to teach a man to fish? I'd very much like to understand in a little more depth exactly what has happened here. Even pointing in the direction of some decent (more specific than rtfm) reference materials would be greatly appreciated. As I understand it, I'm having yet more issues with 32 and 64 bit libraries co-existing or interfering. However, it would be great if I knew precisely what was going on under the surface of that rough understanding.

weibullguy · 11-29-2008, 11:38 AM

Well, Slamd64 is, as of version 12.0 (IIRC), a multilib (i.e., supports 32-bit and 64-bit libraries side by side) OS. This is good (IMO) because the x86_64 architecture was designed to be multilib by the AMD engineers. Of course, you can't put 32-bit libraries and 64-bit libraries in the same directory because they have the same name. Whichever one you install last overwrites the one you installed first.

Fortunately, someone figured out that you could put the 32-bit libraries in /lib, /usr/lib, etc. and the 64-bit libraries in /lib64, /usr/lib64, etc. to keep them separate. This is how the standards expect them to be separated on an x86_64 machine. Even if you don't install 32-bit libraries, the 64-bit libraries live in lib64 on a standards-compliant OS.

When you're building software on a multilib OS, you need to tell the package which ABI to build. First you have the -m32 and -m64 switch to pass to gcc. That's the easy one. Then you need to tell the package where to find the dependency libraries. If you're building a 32-bit app, generally the package will find everything because the 32-bit stuff is in /lib (that's why the 32-bit stuff stayed in /lib, to be backwards compatible) which is the default location for many packages to search.

On the other hand, when you are building 64-bit packages, you need to tell the package explicitly where the 64-bit libraries are. In this case, you have the PKG_CONFIG_PATH environment variable for packages that install a metadata (*.pc) file. This env variable then tells the package to go look in /usr/lib64/pkgconfig for the metadata files. The metadata files contain the real information for building and linking against the package.

You could also carry two PKG_CONFIG_PATH variables, one for the 32-bit paths and one for the 64-bit paths. That's what I do one my machine. Then you would have something like

Code:

weibullguy@aragorn for 2D15h3m $ echo $PKG_CONFIG_PATH32
/usr/lib/pkgconfig:/opt/qt/lib/pkgconfig:/opt/gnome/lib/pkgconfig:/opt/xfce/lib/pkgconfig:/opt/firefox/lib/pkgconfig
57 files(171M bytes) - /home/weibullguy
weibullguy@aragorn for 2D15h3m $ echo $PKG_CONFIG_PATH64
/usr/lib64/pkgconfig:/opt/qt/lib64/pkgconfig:/opt/gnome/lib64/pkgconfig:/opt/xfce/lib64/pkgconfig:/opt/firefox/lib64/pkgconfig:/opt/thunderbird/lib64/pkgconfig

and you would pass them to the real PKG_CONFIG_PATH variable when build a package like

Code:

PKG_CONFIG_PATH="${PKG_CONFIG_PATH32}"

Because the default prefix for applications that use GNU autotools is /usr/local and the default location for the package's libraries is lib, you need to tell the package to put it's libraries in the correct location when you build it for the 64-bit ABI. That is the purpose of the --libdir=/usr/lib64 switch. Even if you use the default prefix, you would need to pass --libdir=/usr/local/lib64.

The packages using GNU autotools are the easiest to deal with on an x86_64 system. Those packages that install a config script like libpng have to be dealt with differently. The problem is, the config scripts are install in the bin directory and there is only one of these (i.e., no bin and bin64). On a CLFS system, we use a wrapper program and then append either -32 or -64 to the config script so applications building against these apps will call the correct config script. This works on Slamd64 too because I've tried it.

Then you have the packages that come with only a Makefile. Many times these work be overriding the default locations from the command line, but in some cases you will need to edit the Makefile by hand (or using sed). If the edits are extensive, then do us all a favor and make a patch.

If you plan to build a lot of packages on your Slamd64 box, take a look at the CBLFS Wiki and/or the Gentoo ebuilds for the package you're working on. These two resources might help you figure out what needs to be done when you run into a problem (CBLFS would have in this case). You could also take a look at #1 in my signature; it works on Slamd64, but is not officially supported on Slamd64 platforms.

shilivan · 01-04-2010, 09:55 AM

I had the exact same problem and this thread gave me the information I needed to get ffmpeg and transcode installed on my Slack64 box. You folks are geniuses. Thanks again!!!