ffmpeg @1.0_2 +gpl2 Patch to allow successful build on PPC Tiger

[ccarey@…]

The ffmpeg @1.0_2 +gpl2 port does not successfully build on PPC Tiger because of

:debug:configure Executing command line:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_multimedia_ffmpeg/ffmpeg/work/ffmpeg-1.0" && ./configure --prefix=/opt/local --enable-swscale --enable-avfilter --enable-libmp3lame --enable-libvorbis --enable-libopus --enable-libtheora --enable-libschroedinger --enable-libopenjpeg --enable-libmodplug --enable-libvpx --enable-libspeex --enable-libfreetype --mandir=/opt/local/share/man --enable-shared --enable-pthreads --cc=/usr/bin/gcc-4.0 --arch=ppc --enable-gpl --enable-postproc --enable-libx264 --enable-libxvid
:info:configure ERROR: libmodplug not found
:info:configure
:info:configure If you think configure made a mistake, make sure you are using the latest
:info:configure version from Git.  If the latest version fails, report the problem to the
:info:configure ffmpeg-user@ffmpeg.org mailing list or IRC #ffmpeg on irc.freenode.net.
:info:configure Include the log file "config.log" produced by configure as this will help
:info:configure solving the problem.
:info:configure Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_multimedia_ffmpeg/ffmpeg/work/ffmpeg-1.0" && ./configure --prefix=/opt/local --enable-swscale --enable-avfilter --enable-libmp3lame --enable-libvorbis --enable-libopus --enable-libtheora --enable-libschroedinger --enable-libopenjpeg --enable-libmodplug --enable-libvpx --enable-libspeex --enable-libfreetype --mandir=/opt/local/share/man --enable-shared --enable-pthreads --cc=/usr/bin/gcc-4.0 --arch=ppc --enable-gpl --enable-postproc --enable-libx264 --enable-libxvid
:info:configure Exit code: 1

This comes from the following line in configure:

enabled libmodplug && require  libmodplug libmodplug/modplug.h ModPlug_Load -lmodplug

The config.log file created by configure shows that the shell functions in the line above eventually resolve into

check_func ModPlug_Load -lmodplug
check_ld cc -lmodplug
check_cc
BEGIN /tmp/ffconf.i2DTrTBU.c
    1   extern int ModPlug_Load();
    2   int main(void){ ModPlug_Load(); }
END /tmp/ffconf.i2DTrTBU.c
/usr/bin/gcc-4.0 -I/opt/local/include -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DPIC -pipe -O2 -DHAVE_LRINTF -I/opt/local/include -arch ppc -std=c99 -fomit-frame-pointer -fPIC -maltivec -mabi=altivec -I/opt/local/include/freetype2 -I/opt/local/include -c -o /tmp/ffconf.VkUK0WDn.o /tmp/ffconf.i2DTrTBU.c
/usr/bin/gcc-4.0 -L/opt/local/lib -arch ppc -Wl,-dynamic,-search_paths_first -o /tmp/ffconf.s1FqMdCL /tmp/ffconf.VkUK0WDn.o -lmodplug -L/opt/local/lib -lfreetype -lm -lbz2 -lz
/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: Undefined symbols:
operator delete[](void*)
operator delete(void*)
operator new[](unsigned long)
operator new(unsigned long)
collect2: ld returned 1 exit status
ERROR: libmodplug not found

— that is, although the file to be compiled is C, and the compiler is instructed to expect the source to be C99, the undefined symbols represent C++ symbols. (Apparently any program using this libmodplug function that is linked against /opt/local/lib/libmodplug.dylib on PPC Tiger requires these C++ symbols.)

I chose to add -lstdc++ to the enabled libmodplug line in configure because it represents the least invasive change to configure. Note that the program being compiled above is not C++, and does not itself use any C++ functions; it is compiled merely as part of the configuration process, to ensure that the sample header, sample library function, and library from port:libmodplug are available.

In addition, the Portfile has been modified in two ways. First, the port:dirac dependency has been removed, since the --enable-libschroedinger option and port:schroedinger dependency render it unnecessary. Second, Altivec detection in the Portfile has been enabled for PPC Macs that have the ppc7450 machine type; this section of the updated Portfile can be expanded to detect other PPC machines with Altivec support (such as G5 models) by providing their corresponding machine values in matching elseif {$machine eq "…"} statements. (I have not done this myself because I only have access to a G4.)

[ccarey@…]

patch to configure to allow ffmpeg @1.0_2 +gpl2 to build successfully on PPC Tiger

[ccarey@…]

patch to the Portfile to allow ffmpeg @1.0_2 +gpl2 to run efficiently on PPC Tiger

[jeremyhu (Jeremy Huddleston Sequoia)]

I would rather figure out the real underlying problem than place this band aid over it.

Is ld picking up any static libraries instead of dylibs? Try using:

LD_TRACE_ARCHIVES=1 LD_TRACE_DYLIBS=1 LD_TRACE_FILE=1

[ccarey@…]

Replying to jeremyhu@…:

Is ld picking up any static libraries instead of dylibs?

No, only dylibs:

[Logging for XBS] Used dynamic library: /opt/local/lib/libmodplug.1.dylib
[Logging for XBS] Used dynamic library: /opt/local/lib/libfreetype.6.dylib
[Logging for XBS] Used dynamic library: /usr/lib/libSystem.B.dylib
[Logging for XBS] Used dynamic library: /opt/local/lib/libbz2.1.0.6.dylib
[Logging for XBS] Used dynamic library: /opt/local/lib/libz.1.2.7.dylib
[Logging for XBS] Used dynamic library: /usr/lib/system/libmathCommon.A.dylib

(For anyone else reading these comments, the value of LD_TRACE_FILE is a pathname, so a more descriptive pathname than “1” might make it easier to remember. I wasn’t previously aware of these environment variables.)

[ccarey@…]

As an experiment, I just compiled libmodplug straight from source (not through MacPorts), and the little C source file links fine with its -lmodplug, not requiring -lstdc++. The non-MacPorts libmodplug.1.dylib is about 1.7 MB, while the MacPorts version is about 0.3 MB. (The only option that I’d provided to the non-MacPorts configure script was a --prefix value.) I’m going to try rebuilding the MacPorts version, to see if anything changes with its libmodplug.1.dylib file.

[ccarey@…]

No behavioral difference with a rebuilt MacPorts port:libmodplug — even after cloning the flags from the non-MacPorts configuration by appending these lines to the Portfile:

platform darwin 8 powerpc {
    configure.cflags-append     -g
    configure.cxxflags-append   -g -fno-exceptions -Wall -ffast-math -D_REENTRANT
    configure.ldflags-delete    -L${prefix}/lib
}

Running nm -pg on both the non-MacPorts dylib and the MacPorts dylib revealed these differences:

2,5c2
< /tmp/goober/lib/libmodplug.1.dylib(single module):
<          U _NSAddressOfSymbol
<          U _NSIsSymbolNameDefinedWithHint
<          U _NSLookupAndBindSymbolWithHint
---
> /opt/local/lib/libmodplug.1.dylib(single module):
28a26
>          U _fprintf$LDBL128
40a39
>          U _printf$LDBL128
49a49
>          U _sprintf$LDBL128
50a51
>          U _sscanf$LDBL128

so there’s still something yet to be identifed compilation-wise that differentiates the non-MacPorts version from the MacPorts version.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to ccarey@…:

(For anyone else reading these comments, the value of LD_TRACE_FILE is a pathname, so a more descriptive pathname than “1” might make it easier to remember. I wasn’t previously aware of these environment variables.)

Ah, right ><

Well I'm still curious where the dependency is coming from.

[ccarey@…]

Replying to jeremyhu@…:

Well I'm still curious where the dependency is coming from.

Seeing as libmodplug is written in C++, I’d imagine that that’s the source of the dependency on the new and delete operators. Why they’re able to be resolved in a non-MacPorts build, but remain unresolved in a MacPorts build, is the question.

The NS…() symbols in comment:4 come from <mach-o/dyld.h>, but neither that header nor those symbols are found anywhere in the libmodplug source, so I’m not sure why they appear in the non-MacPorts dylib. Similarly, no long double is used in the libmodplug source, so I don’t know why the …printf () and sscanf () long double calls are brought into the MacPorts dylib.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ccarey@…:

/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: Undefined symbols:
operator delete[](void*)
operator delete(void*)
operator new[](unsigned long)
operator new(unsigned long)

This is a common problem with Tiger's gcc-4.0. In other ports we've been blacklisting it (thus using apple-gcc42 instead) to fix this problem. See #36226, #37270, #39144.

[cooljeanius (Eric Gallager)]

Cc Me!

[kencu (Ken)]

ffmpeg @3.3.4 installs on Tiger PPC now without issue.