[MacPorts] #21007: mp4v2 build fails on Tiger (libtool: more than one: -current_version option specified)
MacPorts
noreply at macports.org
Tue Oct 6 14:37:28 PDT 2009
#21007: mp4v2 build fails on Tiger (libtool: more than one: -current_version option
specified)
---------------------------------+------------------------------------------
Reporter: vinc17@… | Owner: cedric.luthi@…
Type: defect | Status: new
Priority: Normal | Milestone:
Component: ports | Version:
Keywords: tiger | Port: mp4v2
---------------------------------+------------------------------------------
Comment(by bigger-picture@…):
Replying to [comment:21 fang@…]:
> Cc Me!
"CC Me" too please!
Hi :o) - forgive please any newbie MacPorts-Trac-ticket-system protocol
faux-pas on my part, [[BR]]
but having done already _loads_ of Googling and reading so far, without
resolution, head now [[BR]]
spinning, this is just to add my "Ditto" to this bug-report and hopefully
'bump' the thread. [[BR]]
I'm just sorry that I don't have the necessary up-to-date programming
fluency (yet?) to trace [[BR]]
the error-message through to a solution. For completeness' sake (and
Google-searches) my route [[BR]]
here is as follows..
Apple Macintosh PowerBook (FireWire, 2000, Pismo 500) PPC G3-500 1GB-RAM
[[BR]]
Tiger 10.4.11 Xcode 2.5 MacPorts 1.8.1
The sudden failure on 2009.10.02 of Paul Battley's (po-ru.com) hitherto
extremely useful iPlayer-dl [[BR]]
(following changes _at_the_BBC's_end_ not his), and with the earliest
prospect of a fix more than a [[BR]]
(vacation) week away, the race is on to get an alternative downloader
installed. A tip in his site's [[BR]]
comments mentioned "get_iplayer" (linuxcentre.net/getiplayer) which looks
promising. Unfortunately, [[BR]]
despite finding requests for it here, searching MacPorts shows it
unavailable as a direct install.
Hmm, okay, so trying a roll-yer-own, one-by-one DIY-components approach,
starting with "FFMPEG" as [[BR]]
one of the prerequisites/dependencies for get_iplayer I tried that : "sudo
port install ffmpeg"
And that's where I fell into this mp4v2 libtool make-error hole as per the
thread title above. My [[BR]]
error-messages at the compiler bailout point have been more like Stephen's
2009.09.02 code-snippet [[BR]]
above, except obviously not the i386 references.
From attempting ffmpeg I dropped to mp4v2 directly, firstly trying it
within MacPorts, then even [[BR]]
outside directly from source. Much reading and Googling and thrashing
about in ignorance, I tried [[BR]]
upgrading "make" to v3.81. I tried doing everything in short simple
folder-paths without spaces or [[BR]]
other iffy characters, and I re-checked and simplified my bash $PATH
environment, wondering if the [[BR]]
"more than one current version" might be related to having MacPorts stuff
in the /opt tree [[BR]]
duplicating up on normal system files. I tried using the readme-
recommended strategy of a clean new [[BR]]
/build folder with "mkdir /build ; cd build/ ; ../configure" rather than
my hitherto usual simple [[BR]]
./configure ... all so far without success.
I started looking inside config.log, aclocal.m4, configure.ac,
autoaux/*.*, GNUmakefile*.* and so [[BR]]
forth, searching for any and all references to darwin, ppc, libtool etc,
really grasping at straws, [[BR]]
hoping for enough of a foothold for the old IQ to use, but very quickly
realised I'm out of my [[BR]]
depth, not having any fluency in modern programming contexts, not even
sufficient conceptual [[BR]]
overview of the landscape, let alone the particulars of often-dense and
obfuscating syntax. So no, [[BR]]
not able to trace the error through, sorry. Younger more familiar eyes are
needed.
Given vinc17's comment above, and even Stephen's own caveat, I have not
tried said patch. I did try [[BR]]
some explicit command-line options just in case, and my last (failed)
command-line in a direct build-[[BR]]
from-source folder was : "../configure --enable-bi=32 --enable-ub=ppc"
which fell over similar to [[BR]]
Stephen's, to wit :
{{{
g++ -dynamiclib ${wl}-flat_namespace ${wl}-undefined ${wl}suppress -o
.libs/libmp4v2.1.9.1.dylib src/.libs/3gp.o src/.libs/atom_ac3.o
( ( ( ...snip... ) ) )
libutil/.libs/crc.o libutil/.libs/other.o -arch ppc -m32
-Wl,-current_version -Wl,1.9.1 -Wl,-compatibility_version -Wl,1.0.0
-install_name /usr/local/lib/libmp4v2.1.dylib -compatibility_version 11
-current_version 11.1 -Wl,-single_module
/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/libtool: more than one:
-current_version option specified
Usage: /usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/libtool -static [-]
file [...] [-filelist listfile[,dirname]] [-arch_only arch] [-sacLT]
Usage: /usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/libtool -dynamic [-]
file [...] [-filelist listfile[,dirname]] [-arch_only arch] [-o output]
[-install_name name] [-compatibility_version #] [-current_version #]
[-seg1addr 0x#] [-segs_read_only_addr 0x#] [-segs_read_write_addr 0x#]
[-seg_addr_table <filename>] [-seg_addr_table_filename
<file_system_path>] [-all_load] [-noall_load]
make: *** [libmp4v2.la] Error 1
}}}
Following the MacPorts FAQs and Guides etc, and more for rigour than in
expectation, after a [[BR]]
successful "sudo port -d selfupdate" I'm presently doing the "sudo port -d
upgrade outdated" - it's [[BR]]
been chugging away for a long time already and I suspect it'll be several
days yet before it's [[BR]]
finished on my poor old rig, albeit a faithful old girl. :D
Still, given the 'urgency' of a fix (as the BBC iPlayer streams only last
a week), I thought I'd [[BR]]
at least register and add my slightly different setup case-notes here,
hoping it bumps the thread, [[BR]]
hoping it saves other people wasted hours of thrashing, and hoping it all
maybe snags Googlers [[BR]]
better placed than us to pore over the code.
Thanks to all so far. Keep up the good work.
Fingers crossed.. :o)
..
--
Ticket URL: <http://trac.macports.org/ticket/21007#comment:22>
MacPorts <http://www.macports.org/>
Ports system for Mac OS
More information about the macports-tickets
mailing list