You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan Sperling <st...@apache.org> on 2014/03/13 17:22:04 UTC
-lintl in SVN_INTL_LIBS and LIBS (was: Re: svn commit: r1577223 - in
/subversion/trunk: Makefile.in configure.ac)
On Thu, Mar 13, 2014 at 04:16:17PM -0000, stsp@apache.org wrote:
> Author: stsp
> Date: Thu Mar 13 16:16:16 2014
> New Revision: 1577223
>
> URL: http://svn.apache.org/r1577223
> Log:
> Add libintl link flags to SVN_INTL_LIBS on *nix builds.
>
> The SVN_INTL_LIBS variable was referred to but never defined.
>
> * Makefile.in: Define SVN_INTL_LIBS.
>
> * configure.ac: Set SVN_INTL_LIBS to the linker flags required
> to link to libintl and export the value of SVN_INTL_LIBS
> to the Makefile.
A side-effect of this change is that -lintl now appears in
both SVN_INTL_LIBS and LIBS. It is in LIBS because AC_SEARCH_LIBS
insits on putting it there.
Do we care enough to somehow work around that? Or do we just live
with potential redundant -lintl linker flags?
> Modified:
> subversion/trunk/Makefile.in
> subversion/trunk/configure.ac
>
> Modified: subversion/trunk/Makefile.in
> URL: http://svn.apache.org/viewvc/subversion/trunk/Makefile.in?rev=1577223&r1=1577222&r2=1577223&view=diff
> ==============================================================================
> --- subversion/trunk/Makefile.in (original)
> +++ subversion/trunk/Makefile.in Thu Mar 13 16:16:16 2014
> @@ -48,6 +48,7 @@ SVN_GPG_AGENT_LIBS = @SVN_GPG_AGENT_LIBS
> SVN_GNOME_KEYRING_LIBS = @SVN_GNOME_KEYRING_LIBS@
> SVN_KWALLET_LIBS = @SVN_KWALLET_LIBS@
> SVN_MAGIC_LIBS = @SVN_MAGIC_LIBS@
> +SVN_INTL_LIBS = @SVN_INTL_LIBS@
> SVN_SASL_LIBS = @SVN_SASL_LIBS@
> SVN_SERF_LIBS = @SVN_SERF_LIBS@
> SVN_SQLITE_LIBS = @SVN_SQLITE_LIBS@
>
> Modified: subversion/trunk/configure.ac
> URL: http://svn.apache.org/viewvc/subversion/trunk/configure.ac?rev=1577223&r1=1577222&r2=1577223&view=diff
> ==============================================================================
> --- subversion/trunk/configure.ac (original)
> +++ subversion/trunk/configure.ac Thu Mar 13 16:16:16 2014
> @@ -690,7 +690,10 @@ if test "$enable_nls" = "yes"; then
> AC_PATH_PROG(MSGMERGE, msgmerge, none)
> AC_PATH_PROG(XGETTEXT, xgettext, none)
> if test "$MSGFMT" != "none"; then
> - AC_SEARCH_LIBS(bindtextdomain, [intl], [],
> + AC_SEARCH_LIBS(bindtextdomain, [intl],
> + [
> + SVN_INTL_LIBS="-lintl"
> + ],
> [
> enable_nls="no"
> ])
> @@ -702,9 +705,7 @@ if test "$enable_nls" = "yes"; then
> AC_SEARCH_LIBS(bindtextdomain, [intl],
> [
> enable_nls="yes"
> - # This is here so that -liconv ends up in LIBS
> - # if it worked with -liconv.
> - AC_CHECK_LIB(iconv, libiconv_open)
> + SVN_INTL_LIBS="-lintl -liconv"
> ],
> [
> AC_MSG_WARN([bindtextdomain() not found. Disabling NLS.])
> @@ -720,6 +721,8 @@ if test "$enable_nls" = "yes"; then
> fi
> fi
>
> +AC_SUBST(SVN_INTL_LIBS)
> +
> AH_BOTTOM([
> /* Indicate to translators that string X should be translated. Do not look
> up the translation at run time; just expand to X. This macro is suitable
>
Re: -lintl in SVN_INTL_LIBS and LIBS
Posted by Stefan Sperling <st...@elego.de>.
On Sat, Mar 15, 2014 at 01:44:04PM +0100, Branko Čibej wrote:
> The -lintl "problem" is related to the fact that the symbol is specific
> to the windows project file generator. You should just ignore that
> symbol in the pkg-config file generator; IMO, all this churn in the code
> was quite unnecessary.
The SVN_INTL_LIBS may have been specific to the windows build.
But linking to libintl certainly isn't windows-specfific.
And -lintl is being linked on Unix through LIBS, even though other
libraries like libmagic are handled by flags like SVN_MAGIC_LIBS.
In fact, no other library relies LIBS.
> Does that mean build.conf & co. are not consistent? Sure it does; but
> that's nothing new.
I'd rather clean up these inconsistencies than pile up more hacks on top.
Re: -lintl in SVN_INTL_LIBS and LIBS
Posted by Branko Čibej <br...@wandisco.com>.
On 15.03.2014 12:52, Stefan Sperling wrote:
> On Sat, Mar 15, 2014 at 12:39:19PM +0100, Branko Čibej wrote:
>> On 15.03.2014 11:01, Stefan Sperling wrote:
>>> On Sat, Mar 15, 2014 at 09:56:17AM +0100, Branko Čibej wrote:
>>>> It's really simple: given the nature of our build system, you'll have to
>>>> try harder. I suggest generating the final .pc files during 'make
>>>> install' -- or a separate make target that 'make install' depends on --
>>>> not during configure time.
>>> What problem would that solve?
>> Doing this from 'make' allows you to filter the symbols to expand to
>> $(STUFF). If you can do that from configure, fine; but I believe you
>> can't avoid additional filtering in general.
> Well, apart from the -lintl problem the generated files seem fine.
> If I run into further issues down the road I'll consider generating
> them from the Makefile instead of from configure.
The -lintl "problem" is related to the fact that the symbol is specific
to the windows project file generator. You should just ignore that
symbol in the pkg-config file generator; IMO, all this churn in the code
was quite unnecessary.
Does that mean build.conf & co. are not consistent? Sure it does; but
that's nothing new.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: -lintl in SVN_INTL_LIBS and LIBS
Posted by Stefan Sperling <st...@elego.de>.
On Sat, Mar 15, 2014 at 12:39:19PM +0100, Branko Čibej wrote:
> On 15.03.2014 11:01, Stefan Sperling wrote:
> > On Sat, Mar 15, 2014 at 09:56:17AM +0100, Branko Čibej wrote:
> >> It's really simple: given the nature of our build system, you'll have to
> >> try harder. I suggest generating the final .pc files during 'make
> >> install' -- or a separate make target that 'make install' depends on --
> >> not during configure time.
> > What problem would that solve?
>
> Doing this from 'make' allows you to filter the symbols to expand to
> $(STUFF). If you can do that from configure, fine; but I believe you
> can't avoid additional filtering in general.
Well, apart from the -lintl problem the generated files seem fine.
If I run into further issues down the road I'll consider generating
them from the Makefile instead of from configure.
Re: -lintl in SVN_INTL_LIBS and LIBS
Posted by Branko Čibej <br...@wandisco.com>.
On 15.03.2014 11:01, Stefan Sperling wrote:
> On Sat, Mar 15, 2014 at 09:56:17AM +0100, Branko Čibej wrote:
>> It's really simple: given the nature of our build system, you'll have to
>> try harder. I suggest generating the final .pc files during 'make
>> install' -- or a separate make target that 'make install' depends on --
>> not during configure time.
> What problem would that solve?
Doing this from 'make' allows you to filter the symbols to expand to
$(STUFF). If you can do that from configure, fine; but I believe you
can't avoid additional filtering in general.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: -lintl in SVN_INTL_LIBS and LIBS
Posted by Stefan Sperling <st...@elego.de>.
On Sat, Mar 15, 2014 at 09:56:17AM +0100, Branko Čibej wrote:
> It's really simple: given the nature of our build system, you'll have to
> try harder. I suggest generating the final .pc files during 'make
> install' -- or a separate make target that 'make install' depends on --
> not during configure time.
What problem would that solve?
Re: -lintl in SVN_INTL_LIBS and LIBS
Posted by Branko Čibej <br...@wandisco.com>.
On 14.03.2014 23:06, Stefan Sperling wrote:
> On Fri, Mar 14, 2014 at 10:47:28PM +0100, Branko Čibej wrote:
>> And of course you can't tweak the generator to ignore symbols that are
>> not expanded, is that what you're saying? :)
> Indeed, we cannot.
No comment ...
> I'm generating pc.in files from build.conf to avoid having to
> maintain duplicate dependency information for pkg-config support.
>
> So we first generate .pc.in files from build.conf. At this stage,
> we parse build.conf to see which variables could be expanded.
> If we see $(SVN_INTL_LIBS) we put @SVN_INTL_LIBS@ in the pc.in file.
> This part is what this discussion is about. And it is the only part
> we can write code for.
>
> Later we generate .pc files from .pc.in files using a pre-defined
> autotools macro we don't control. It's done like this:
> AC_CONFIG_FILES([${pc_file}])
> This happens at the end of the configure script. At this stage we
> perform substitutions of the form @SVN_INTL_LIBS@ -> -lsomething
> depending on what the configure script found.
It's really simple: given the nature of our build system, you'll have to
try harder. I suggest generating the final .pc files during 'make
install' -- or a separate make target that 'make install' depends on --
not during configure time.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: -lintl in SVN_INTL_LIBS and LIBS
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Mar 14, 2014 at 10:47:28PM +0100, Branko Čibej wrote:
> And of course you can't tweak the generator to ignore symbols that are
> not expanded, is that what you're saying? :)
Indeed, we cannot.
I'm generating pc.in files from build.conf to avoid having to
maintain duplicate dependency information for pkg-config support.
So we first generate .pc.in files from build.conf. At this stage,
we parse build.conf to see which variables could be expanded.
If we see $(SVN_INTL_LIBS) we put @SVN_INTL_LIBS@ in the pc.in file.
This part is what this discussion is about. And it is the only part
we can write code for.
Later we generate .pc files from .pc.in files using a pre-defined
autotools macro we don't control. It's done like this:
AC_CONFIG_FILES([${pc_file}])
This happens at the end of the configure script. At this stage we
perform substitutions of the form @SVN_INTL_LIBS@ -> -lsomething
depending on what the configure script found.
Re: -lintl in SVN_INTL_LIBS and LIBS
Posted by Branko Čibej <br...@wandisco.com>.
On 14.03.2014 12:11, Stefan Sperling wrote:
> On Fri, Mar 14, 2014 at 10:44:27AM +0000, Philip Martin wrote:
>> I still don't understand what is being attempted. SVN_INTL_LIBS is some
>> Windows feature. Why do we need to support it on Unix? Can we just
>> leave it empty? Why put in extra code to move '-lintl' from LIBS to
>> SVN_INTL_LIBS?
> pkg-config needs to provide accurate linker flags to applications
> linking to Subversion. If libsvn_subr requires -lintl to link,
> then -lintl needs to be listed in the pkg-config file for libsvn_subr.
>
> As I understand so far, -lintl is not required on Linux but is
> required on other systems like Mac OS X or *BSD.
>
> The pkg-config generator derives linker flags like -lintl from
> variables like SVN_INTL_LIBS, which are referenced in build.conf.
> E.g. SVN_INTL_LIBS is referenced by the [intl] section in build.conf.
And of course you can't tweak the generator to ignore symbols that are
not expanded, is that what you're saying? :)
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: -lintl in SVN_INTL_LIBS and LIBS
Posted by Philip Martin <ph...@wandisco.com>.
Stefan Sperling <st...@elego.de> writes:
> Would something like this work on linux?
>
> I'm now afraid of breaking the build for everyone else with
> changes like these :)
Works on Linux, but please avoid "grep -q" and redirect to >/dev/null
instead.
$ ../src/configure
...
checking for xgettext... /usr/bin/xgettext
checking for library containing bindtextdomain... none required
checking for bind_textdomain_codeset... yes
checking if we are using GNU gettext... yes
...
$ grep INTL Makefile
SVN_INTL_LIBS =
$ grep NLS subversion/svn_private_config.h
#define ENABLE_NLS 1
#ifdef ENABLE_NLS
>
> Index: configure.ac
> ===================================================================
> --- configure.ac (revision 1577708)
> +++ configure.ac (working copy)
> @@ -684,6 +684,7 @@ AC_ARG_ENABLE(nls,
> [enable_nls=$enableval],[enable_nls=yes])
>
> USE_NLS="no"
> +SVN_INTL_LIBS=""
> if test "$enable_nls" = "yes"; then
> dnl First, check to see if there is a working msgfmt.
> AC_PATH_PROG(MSGFMT, msgfmt, none)
> @@ -690,8 +691,16 @@ if test "$enable_nls" = "yes"; then
> AC_PATH_PROG(MSGMERGE, msgmerge, none)
> AC_PATH_PROG(XGETTEXT, xgettext, none)
> if test "$MSGFMT" != "none"; then
> - AC_SEARCH_LIBS(bindtextdomain, [intl], [],
> + AC_SEARCH_LIBS(bindtextdomain, [intl],
> [
> + # in case libintl needs to be linked explicitly,
> + # $ac_cv_search_bindtextdomain contains -l linker flags
> + if echo "$ac_cv_search_bindtextdomain" | grep -q '^-l'
> + then
> + SVN_INTL_LIBS="$ac_cv_search_bindtextdomain"
> + fi
> + ],
> + [
> enable_nls="no"
> ])
> if test "$enable_nls" = "no"; then
> @@ -702,6 +711,10 @@ if test "$enable_nls" = "yes"; then
> AC_SEARCH_LIBS(bindtextdomain, [intl],
> [
> enable_nls="yes"
> + if echo "$ac_cv_search_bindtextdomain" | grep -q '^-l'
> + then
> + SVN_INTL_LIBS="$ac_cv_search_bindtextdomain"
> + fi
> # This is here so that -liconv ends up in LIBS
> # if it worked with -liconv.
> AC_CHECK_LIB(iconv, libiconv_open)
> @@ -720,7 +733,6 @@ if test "$enable_nls" = "yes"; then
> fi
> fi
>
> -dnl Currently SVN_INTL_LIBS is always empty.
> AC_SUBST(SVN_INTL_LIBS)
>
> AH_BOTTOM([
>
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: -lintl in SVN_INTL_LIBS and LIBS
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Mar 14, 2014 at 12:17:54PM +0000, Philip Martin wrote:
> Stefan Sperling <st...@elego.de> writes:
>
> > One possible solution to this problem is to make sure that SVN_INTL_LIBS
> > is always defined, either to an empty string, or to the appropriate
> > linke flags (e.g. "-lintl", or "-lintl -liconv").
> > This is what I want to achieve.
>
> The docs for AC_SEARCH_LIB say you can check the variable
> ac_cv_search_bindtextdomian to determine whether a library was needed
> but it might be simpler to simply do an AC_LINKIFELSE to see if it works
> with no library and AC_CHECK_LIB for -lintl if it fails.
Would something like this work on linux?
I'm now afraid of breaking the build for everyone else with
changes like these :)
Index: configure.ac
===================================================================
--- configure.ac (revision 1577708)
+++ configure.ac (working copy)
@@ -684,6 +684,7 @@ AC_ARG_ENABLE(nls,
[enable_nls=$enableval],[enable_nls=yes])
USE_NLS="no"
+SVN_INTL_LIBS=""
if test "$enable_nls" = "yes"; then
dnl First, check to see if there is a working msgfmt.
AC_PATH_PROG(MSGFMT, msgfmt, none)
@@ -690,8 +691,16 @@ if test "$enable_nls" = "yes"; then
AC_PATH_PROG(MSGMERGE, msgmerge, none)
AC_PATH_PROG(XGETTEXT, xgettext, none)
if test "$MSGFMT" != "none"; then
- AC_SEARCH_LIBS(bindtextdomain, [intl], [],
+ AC_SEARCH_LIBS(bindtextdomain, [intl],
[
+ # in case libintl needs to be linked explicitly,
+ # $ac_cv_search_bindtextdomain contains -l linker flags
+ if echo "$ac_cv_search_bindtextdomain" | grep -q '^-l'
+ then
+ SVN_INTL_LIBS="$ac_cv_search_bindtextdomain"
+ fi
+ ],
+ [
enable_nls="no"
])
if test "$enable_nls" = "no"; then
@@ -702,6 +711,10 @@ if test "$enable_nls" = "yes"; then
AC_SEARCH_LIBS(bindtextdomain, [intl],
[
enable_nls="yes"
+ if echo "$ac_cv_search_bindtextdomain" | grep -q '^-l'
+ then
+ SVN_INTL_LIBS="$ac_cv_search_bindtextdomain"
+ fi
# This is here so that -liconv ends up in LIBS
# if it worked with -liconv.
AC_CHECK_LIB(iconv, libiconv_open)
@@ -720,7 +733,6 @@ if test "$enable_nls" = "yes"; then
fi
fi
-dnl Currently SVN_INTL_LIBS is always empty.
AC_SUBST(SVN_INTL_LIBS)
AH_BOTTOM([
Re: -lintl in SVN_INTL_LIBS and LIBS
Posted by Philip Martin <ph...@wandisco.com>.
Stefan Sperling <st...@elego.de> writes:
> One possible solution to this problem is to make sure that SVN_INTL_LIBS
> is always defined, either to an empty string, or to the appropriate
> linke flags (e.g. "-lintl", or "-lintl -liconv").
> This is what I want to achieve.
The docs for AC_SEARCH_LIB say you can check the variable
ac_cv_search_bindtextdomian to determine whether a library was needed
but it might be simpler to simply do an AC_LINKIFELSE to see if it works
with no library and AC_CHECK_LIB for -lintl if it fails.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: -lintl in SVN_INTL_LIBS and LIBS
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Mar 14, 2014 at 10:44:27AM +0000, Philip Martin wrote:
> I still don't understand what is being attempted. SVN_INTL_LIBS is some
> Windows feature. Why do we need to support it on Unix? Can we just
> leave it empty? Why put in extra code to move '-lintl' from LIBS to
> SVN_INTL_LIBS?
pkg-config needs to provide accurate linker flags to applications
linking to Subversion. If libsvn_subr requires -lintl to link,
then -lintl needs to be listed in the pkg-config file for libsvn_subr.
As I understand so far, -lintl is not required on Linux but is
required on other systems like Mac OS X or *BSD.
The pkg-config generator derives linker flags like -lintl from
variables like SVN_INTL_LIBS, which are referenced in build.conf.
E.g. SVN_INTL_LIBS is referenced by the [intl] section in build.conf.
Because SVN_INTL_LIBS was never defined, the generated pkg-config
contained linker flags like: -lsvn_subr $(SVN_INTL_LIBS)
i.e. a litereral string "$(SVN_INTL_LIBS)" instead of an expansion.
A hack was put in place to ignore the [intl] section in build.conf
to avoid this problem for now. But that hack means we don't provide
correct linker flags for libsvn_subr on all platforms.
One possible solution to this problem is to make sure that SVN_INTL_LIBS
is always defined, either to an empty string, or to the appropriate
linke flags (e.g. "-lintl", or "-lintl -liconv").
This is what I want to achieve.
Re: -lintl in SVN_INTL_LIBS and LIBS
Posted by Philip Martin <ph...@wandisco.com>.
Stefan Sperling <st...@elego.de> writes:
> On Thu, Mar 13, 2014 at 05:46:35PM +0000, Philip Martin wrote:
>> Stefan Sperling <st...@apache.org> writes:
>>
>> > On Thu, Mar 13, 2014 at 04:16:17PM -0000, stsp@apache.org wrote:
>> >> Author: stsp
>> >> Date: Thu Mar 13 16:16:16 2014
>> >> New Revision: 1577223
>>
>> >> - AC_SEARCH_LIBS(bindtextdomain, [intl], [],
>> >> + AC_SEARCH_LIBS(bindtextdomain, [intl],
>> >> + [
>> >> + SVN_INTL_LIBS="-lintl"
>>
>> That's not correct. AC_SEARCH_LIBS will start with no libs and will only
>> go on to check libintl if it doesn't find the symbol. At this point we
>> don't know whether libintl was needed or whether it worked without.
>
> Ah, I see. So we'll probably need to set LIBS to an empty string,
> and then check if it was set to anything by AC_SEARCH_LIBS?
>
>> I'm still not really sure why we are trying to set SVN_INTL_LIBS at
>> all. Why is LIBS not enough?
>
> Because otherwise it requires a special hack during pkg-config
> file generation. See r1577226 which removed the hack.
I still don't understand what is being attempted. SVN_INTL_LIBS is some
Windows feature. Why do we need to support it on Unix? Can we just
leave it empty? Why put in extra code to move '-lintl' from LIBS to
SVN_INTL_LIBS?
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: -lintl in SVN_INTL_LIBS and LIBS
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Mar 13, 2014 at 05:46:35PM +0000, Philip Martin wrote:
> Stefan Sperling <st...@apache.org> writes:
>
> > On Thu, Mar 13, 2014 at 04:16:17PM -0000, stsp@apache.org wrote:
> >> Author: stsp
> >> Date: Thu Mar 13 16:16:16 2014
> >> New Revision: 1577223
>
> >> - AC_SEARCH_LIBS(bindtextdomain, [intl], [],
> >> + AC_SEARCH_LIBS(bindtextdomain, [intl],
> >> + [
> >> + SVN_INTL_LIBS="-lintl"
>
> That's not correct. AC_SEARCH_LIBS will start with no libs and will only
> go on to check libintl if it doesn't find the symbol. At this point we
> don't know whether libintl was needed or whether it worked without.
Ah, I see. So we'll probably need to set LIBS to an empty string,
and then check if it was set to anything by AC_SEARCH_LIBS?
> I'm still not really sure why we are trying to set SVN_INTL_LIBS at
> all. Why is LIBS not enough?
Because otherwise it requires a special hack during pkg-config
file generation. See r1577226 which removed the hack.
Re: -lintl in SVN_INTL_LIBS and LIBS
Posted by Philip Martin <ph...@wandisco.com>.
Stefan Sperling <st...@apache.org> writes:
> On Thu, Mar 13, 2014 at 04:16:17PM -0000, stsp@apache.org wrote:
>> Author: stsp
>> Date: Thu Mar 13 16:16:16 2014
>> New Revision: 1577223
>> - AC_SEARCH_LIBS(bindtextdomain, [intl], [],
>> + AC_SEARCH_LIBS(bindtextdomain, [intl],
>> + [
>> + SVN_INTL_LIBS="-lintl"
That's not correct. AC_SEARCH_LIBS will start with no libs and will only
go on to check libintl if it doesn't find the symbol. At this point we
don't know whether libintl was needed or whether it worked without.
I'm still not really sure why we are trying to set SVN_INTL_LIBS at
all. Why is LIBS not enough?
>> + ],
>> [
>> enable_nls="no"
>> ])
>> @@ -702,9 +705,7 @@ if test "$enable_nls" = "yes"; then
>> AC_SEARCH_LIBS(bindtextdomain, [intl],
>> [
>> enable_nls="yes"
>> - # This is here so that -liconv ends up in LIBS
>> - # if it worked with -liconv.
>> - AC_CHECK_LIB(iconv, libiconv_open)
>> + SVN_INTL_LIBS="-lintl -liconv"
>> ],
>> [
>> AC_MSG_WARN([bindtextdomain() not found. Disabling NLS.])
>> @@ -720,6 +721,8 @@ if test "$enable_nls" = "yes"; then
>> fi
>> fi
>>
>> +AC_SUBST(SVN_INTL_LIBS)
>> +
>> AH_BOTTOM([
>> /* Indicate to translators that string X should be translated. Do not look
>> up the translation at run time; just expand to X. This macro is suitable
>>
>
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: -lintl in SVN_INTL_LIBS and LIBS
Posted by Branko Čibej <br...@wandisco.com>.
On 13.03.2014 17:22, Stefan Sperling wrote:
> On Thu, Mar 13, 2014 at 04:16:17PM -0000, stsp@apache.org wrote:
>> Author: stsp
>> Date: Thu Mar 13 16:16:16 2014
>> New Revision: 1577223
>>
>> URL: http://svn.apache.org/r1577223
>> Log:
>> Add libintl link flags to SVN_INTL_LIBS on *nix builds.
>>
>> The SVN_INTL_LIBS variable was referred to but never defined.
>>
>> * Makefile.in: Define SVN_INTL_LIBS.
>>
>> * configure.ac: Set SVN_INTL_LIBS to the linker flags required
>> to link to libintl and export the value of SVN_INTL_LIBS
>> to the Makefile.
> A side-effect of this change is that -lintl now appears in
> both SVN_INTL_LIBS and LIBS. It is in LIBS because AC_SEARCH_LIBS
> insits on putting it there.
>
> Do we care enough to somehow work around that? Or do we just live
> with potential redundant -lintl linker flags?
We should try to reset LIBS during AC_SEARCH_LIBS for gettext & co.
IIRC, we do something similar for SQLite.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com