tobhahn at web
Sep 12, 2006, 5:04 AM
Post #5 of 9
(4805 views)
Permalink
|
I had similar issues once, my guess is the following: /usr/bin/
libtool is the Darwin libtool, not the GNU libtool you emerged
before. I don't know enough about prefix-portage to tell it which
libtool to use, but I guess that's the problem to solve.
Tobias
>> /usr/bin/libtool: unknown option character `o' in: -soname
>> Usage: /usr/bin/libtool -static [-] file [...] [-filelist
>> listfile[,dirname]] [-arch_only arch] [-sacLT]
>> Usage: /usr/bin/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: *** [libperl.1.5.8.dylib] Error 1
>>
>
> This looks like some similar problem I had on ia64-hpux, where
> native ld
> does not understand -soname.
> But wait, questions came up while reading your errormessage thrice:
> Seems that your /usr/bin/libtool does not understand -soname ?
> Didn't you have libtool-1.5.22 emerged just before to eprefix ?
> Shouldn't this be passed to linker using -Wl, rather than libtool ?
>
Am 12.09.2006 um 08:45 schrieb Michael Haubenwallner:
> On Mon, 2006-09-11 at 19:34 -0400, Chris L. Mason wrote:
> <snip>
>
>> libperl-5.8.8 fails:
>>
>> env MACOSX_DEPLOYMENT_TARGET=10.3 cc -o libperl.1.5.8.dylib
>> -L/usr/local/lib -L/opt/local/lib -dynamiclib
>> -compatibility_version 5.8.0
>> -current_version 5.8.8
>> -install_name /gentoo/usr/lib/perl5/5.8.8/darwin-2level/CORE/
>> libperl.1.5.8.dylib
>> perl.o gv.o toke.o perly.o o
>> p.o pad.o regcomp.o dump.o util.o mg.o reentr.o hv.o av.o run.o
>> pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o
>> utf8.o taint.o deb.o universal.o xsutils.o g
>> lobals.o perlio.o perlapi.o numeric.o locale.o pp_pack.o pp_sort.o
>> -ldl -lm -lc -Wl,-soname -Wl,libperl.so.`echo libperl.1.5.8.dylib |
>> cut -d. -f3`
>> /usr/bin/libtool: unknown option character `o' in: -soname
>> Usage: /usr/bin/libtool -static [-] file [...] [-filelist
>> listfile[,dirname]] [-arch_only arch] [-sacLT]
>> Usage: /usr/bin/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: *** [libperl.1.5.8.dylib] Error 1
>>
>
> This looks like some similar problem I had on ia64-hpux, where
> native ld
> does not understand -soname.
> But wait, questions came up while reading your errormessage thrice:
> Seems that your /usr/bin/libtool does not understand -soname ?
> Didn't you have libtool-1.5.22 emerged just before to eprefix ?
> Shouldn't this be passed to linker using -Wl, rather than libtool ?
>
> Anyway:
>
> libperl-5.8.7.ebuild assumes using GNU ld if userland != Darwin,
> applying a patch called "${PN}-create-libperl-soname.patch".
> Do you have userland set to Darwin ?
>
> I'm not sure how to decide when to apply this patch, in
> libperl-5.8.7 it
> was done for non-Darwin userland only:
> use userland_Darwin || epatch ${FILESDIR}/${PN}-create-libperl-
> soname.patch
>
> On ia64-hpux i'm doing this based on CHOST now (will work for hppa-
> hpux
> too), but IMHO this nothing but a quick-hack:
> ( use userland_Darwin || [[ ${CHOST} = *-*-hpux* ]] ) ||
> epatch ${FILESDIR}/${PN}-create-libperl-soname.patch
>
> Maybe I should do with 'use ia64-hpux' ?
>
> Same problem applies for perl itself lateron.
>
> Maybe we should introduce another global use-flags both for GNU-as and
> GNU-ld ?
> Because there are some platform out there, where both GNU and native
> as/ld will work, and others where only GNU as works, but GNU ld does
> not, and others where none of the GNU binutils work.
>
> -haubi-
> --
> Michael Haubenwallner SALOMON Automation GmbH
> Forschung & Entwicklung A-8114 Friesach bei Graz
> mailto:michael.haubenwallner [at] salomon http://www.salomon.at
> No HTML/MIME please, see http://expita.com/nomime.html
>
> --
> gentoo-osx [at] gentoo mailing list
>
--
gentoo-osx [at] gentoo mailing list
|
