[MacPorts] #36942: ffmpeg @1.0_2 +gpl2 Patch to allow successful build on PPC Tiger
#36942: ffmpeg @1.0_2 +gpl2 Patch to allow successful build on PPC Tiger ----------------------------+-------------------------------- Reporter: ccarey@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Keywords: tiger haspatch | Port: ffmpeg ----------------------------+-------------------------------- 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.) -- Ticket URL: <https://trac.macports.org/ticket/36942> MacPorts <http://www.macports.org/> Ports system for Mac OS
#36942: ffmpeg @1.0_2 +gpl2 Patch to allow successful build on PPC Tiger -----------------------+-------------------------------- Reporter: ccarey@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: tiger haspatch Port: ffmpeg | -----------------------+-------------------------------- Comment (by jeremyhu@…): 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 -- Ticket URL: <https://trac.macports.org/ticket/36942#comment:1> MacPorts <http://www.macports.org/> Ports system for Mac OS
#36942: ffmpeg @1.0_2 +gpl2 Patch to allow successful build on PPC Tiger -----------------------+-------------------------------- Reporter: ccarey@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: tiger haspatch Port: ffmpeg | -----------------------+-------------------------------- Comment (by ccarey@…): Replying to [comment:1 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.) -- Ticket URL: <https://trac.macports.org/ticket/36942#comment:2> MacPorts <http://www.macports.org/> Ports system for Mac OS
#36942: ffmpeg @1.0_2 +gpl2 Patch to allow successful build on PPC Tiger -----------------------+-------------------------------- Reporter: ccarey@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: tiger haspatch Port: ffmpeg | -----------------------+-------------------------------- Comment (by 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. -- Ticket URL: <https://trac.macports.org/ticket/36942#comment:3> MacPorts <http://www.macports.org/> Ports system for Mac OS
#36942: ffmpeg @1.0_2 +gpl2 Patch to allow successful build on PPC Tiger -----------------------+-------------------------------- Reporter: ccarey@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: tiger haspatch Port: ffmpeg | -----------------------+-------------------------------- Comment (by 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. -- Ticket URL: <https://trac.macports.org/ticket/36942#comment:4> MacPorts <http://www.macports.org/> Ports system for Mac OS
#36942: ffmpeg @1.0_2 +gpl2 Patch to allow successful build on PPC Tiger -----------------------+-------------------------------- Reporter: ccarey@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: tiger haspatch Port: ffmpeg | -----------------------+-------------------------------- Comment (by jeremyhu@…): Replying to [comment:2 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. -- Ticket URL: <https://trac.macports.org/ticket/36942#comment:5> MacPorts <http://www.macports.org/> Ports system for Mac OS
#36942: ffmpeg @1.0_2 +gpl2 Patch to allow successful build on PPC Tiger -----------------------+-------------------------------- Reporter: ccarey@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: tiger haspatch Port: ffmpeg | -----------------------+-------------------------------- Comment (by ccarey@…): Replying to [comment:5 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. -- Ticket URL: <https://trac.macports.org/ticket/36942#comment:6> MacPorts <http://www.macports.org/> Ports system for Mac OS
#36942: ffmpeg @1.0_2 +gpl2 Patch to allow successful build on PPC Tiger -----------------------+-------------------------------- Reporter: ccarey@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Resolution: | Keywords: tiger haspatch Port: ffmpeg | -----------------------+-------------------------------- Comment (by ryandesign@…): Replying to [ticket:36942 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. -- Ticket URL: <https://trac.macports.org/ticket/36942#comment:7> MacPorts <http://www.macports.org/> Ports system for OS X
participants (1)
-
MacPorts