[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-gettext] gettext and -R
From: |
Ryan Schmidt |
Subject: |
Re: [bug-gettext] gettext and -R |
Date: |
Thu, 2 Oct 2014 08:22:10 -0500 |
Thanks for your reply!
On Oct 2, 2014, at 4:23 AM, Daiki Ueno wrote:
> Ryan Schmidt writes:
>
>> LTLIBICONV = -L/opt/local/lib -liconv -R/opt/local/lib
>
> Thanks for the report and investigation. However, I don't think this is
> the root cause of the problem, because the '-R' option is handled
> specially by libtool:
> https://www.gnu.org/software/libtool/manual/libtool.html#Link-mode and
> translated into a portable option.
>
>> Because I am using a recent version of clang ("Apple LLVM version 6.0
>> (clang-600.0.54) (based on LLVM 3.5svn)"), this in turn causes the build of
>> the other package to fail with this error:
>>
>> clang: error: unknown argument: '-R/opt/local/lib'
>
> Could you provide the full build log?
Sure, here it is:
http://ryandesign.com/tmp/tuxtype-1.8.3.main.log
As far as I can tell, libtool is not being used; the flags are going directly
to the compiler.
The source can be downloaded from git://git.debian.org/git/tux4kids/tuxtype.git
> I can't reproduce it with an
> older version of clang ("Apple clang version 4.1
> (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)").
Unknown arguments have only been an error in clang since "Apple LLVM version
5.1".
> I have a similar
> line in Makefiles:
>
> LTLIBICONV = -L/usr/local/lib -liconv -R/usr/local/lib
>
> and '-R' option is given to a libtool call:
>
> /bin/sh ../libtool --tag=CC --mode=link \
> clang -I/usr/local/include -g -O2 -fvisibility=hidden -o libintl.la \
> bindtextdom.lo ... -L/usr/local/lib -liconv -R/usr/local/lib
> -Wl,-framework -Wl,CoreFoundation -lc \
> -version-info 9:2:1 \
> -rpath /usr/local/lib \
> -no-undefined
>
> The command-line is translated into:
>
> libtool: link: clang -dynamiclib -o .libs/libintl.8.dylib
> .libs/bindtextdom.o ... -L/usr/local/lib /usr/local/lib/libiconv.dylib -lc
> -O2 -Wl,-framework -Wl,CoreFoundation -install_name
> /usr/local/lib/libintl.8.dylib -compatibility_version 10 -current_version
> 10.2 -Wl,-single_module
>
> Perhaps it might be just stripped off because /usr/local/lib is a
> standard library location?
I think you're talking about building gettext itself here, but I'm talking
about building other software that uses gettext.