[Top][All Lists]

[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:


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 

> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]