Re: [PATCH] Re: libtool-2.4.2 is fine but libtool-2.4.6 very slow.
On Wednesday 23 of September 2015 16:09:49 Eric Blake wrote: > On 09/23/2015 03:37 PM, Pavel Raiskup wrote: > > > > >>From 5e8a4c5173f1aa0786e8eba15fb07bfe04b83862 Mon Sep 17 00:00:00 2001 > > From: Pavel Raiskup > > Date: Fri, 18 Sep 2015 23:17:07 +0200 > > Subject: [PATCH] libtoolize: fix infinite recursion in m4 > > > > Some projects use this construct in configure.ac: > > > > m4_define([version], m4_include([version]) > > Missing a ) > > The faulty package used: > > m4_define([version], m4_include(version)) Thanks for catching the ')' typo! > and the infinite recursion occurred _because_ the usage was underquoted. > But as you wrote things here, you have sufficient quoting that you > won't trigger infinite recursion. > You need to drop the second [] for > this to be an accurate representation of the failure. I intentionally added the '[ ]' quotes there as that is something which would look like correct usage, but it still goes to infinite recursion. The problem is that while defining 'version': m4_define([version], m4_include([version])) The expansion is like 'version => m4_include(version)'. Then, usage of 'version' goes to infinite recursion. > > pkg_version=version > > > > When the m4_include builtin is undefined (as was done in > > libtoolize and extract-trace scripts), the call to this 'version' > > macro gone to infinite recursion (until ENOMEM). So rather > > s/gone to infinite/enters an infinite/ > > > re-define all potentially dangerous macros by empty strings, > > suggested by Eric Blake. > > > > While we are on it, merge the macro-"blacklist" with similar list > > implemented in gettext, except the 'm4_esyscmd'. It's kept > > s/except the/except for/ > > > defined because we already trace AC_INIT macro for package > > version, while it is often specified by > > m4_esyscmd(git-version-gen). Similarly to m4_include, m4_esyscmd > > might be opt-in-blacklisted in future. > > > > References: > > http://lists.gnu.org/archive/html/libtool/2015-09/msg0.html > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764580 > > > > With the commit message touched up, it looks okay to me. I'll fix the typos, thanks! Pavel
Re: Bug: linking shared libraries on Cygwin results in undefined references to __stack_chck_guard for code compiled with -fstack-protector
Le 02/11/13 23:45, Richard PALO a écrit :
> Le 02/06/10 05:24, Yaakov (Cygwin/X) a écrit :
>> On Sat, 15 May 2010 09:07:49 +0200
>> Bart Van Assche wrote:
>>> This behavior has been observed with libtool version 2.2.6.
>>
>> Bug confirmed. When code is compiled with -fstack-protector{,-all},
>> GCC "emits extra code to check for buffer overflows, such as stack
>> smashing attacks". This extra code uses symbols from libssp, and
>> therefore (at least) Cygwin's GCC specs contain:
>>
>> *link_ssp:
>> %{fstack-protector|fstack-protector-all:-lssp_nonshared -lssp}
>>
>> Therefore, when libtool fails to pass -fstack-protector{,-all} at link
>> stage, the link fails.
>>
>> Patch attached. (Yes, I have a copyright assignment on file.)
>>
>>
>> Yaakov
>> Cygwin/X
>>
>
> I've done some limited testing of this patch on a SunOS distro with
> pkgsrc, and it certainly helps a number of cases since it is gcc that
> generates the necessary '-lssp_nonshared -lssp' libs for linking (at
> least in absence of '-nostdlib').
>
> Please include in the upcoming version.
>
>
>
>
I'd like to propose a slight modification this which, in addition, seems to get
over the
issue (at least on solaris) of c++ shared libraries linking '-nostdlib'.
This could easily be adapted for other hosts using g++. Note, it is harmless if
'-dumpspecs'
or no spec with fstack-protector* is available.
It appears there was no warm welcome in tossing the '-nostdlib' setup for g++
shared libraries
for solaris, so this seems to be a reasonable workaround.
--
Richard PALO
>From 5dfcf84c8243441f30a3c852791b8d46bc4d2c53 Mon Sep 17 00:00:00 2001
From: Richard PALO
Date: Thu, 24 Sep 2015 13:23:56 +0200
Subject: [PATCH] workaround for -nostdlib with -fstack-protector on solaris
---
build-aux/ltmain.in | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 0c40da0..7a6356b 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -5364,8 +5364,7 @@ func_mode_link ()
# -stdlib=*select c++ std lib with clang
-64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \
-t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*|-tp=*|--sysroot=*| \
- -O*|-g*|-flto*|-fwhopr*|-fuse-linker-plugin|-fstack-protector*|-stdlib=*| \
- -specs=*)
+ -O*|-g*|-flto*|-fwhopr*|-fuse-linker-plugin|-stdlib=*|-specs=*)
func_quote_for_eval "$arg"
arg=$func_quote_for_eval_result
func_append compile_command " $arg"
@@ -5374,6 +5373,25 @@ func_mode_link ()
continue
;;
+ -fstack-protector*)
+func_quote_for_eval "$arg"
+arg=$func_quote_for_eval_result
+func_append compile_command " $arg"
+func_append finalize_command " $arg"
+func_append compiler_flags " $arg"
+
+# Explicitly add solaris ssp libs to postdeps to counter
+# linking with g++ -nostdlib when supplied -fstack-protector*
+test CXX = "$tagname" && {
+ case $host_os in
+ solaris*)
+func_append postdeps " `$compile_command -dumpspecs 2>/dev/null | $SED -n '/fstack-protector/{s/^.*://;s/}$//;p;}'`"
+;;
+ esac
+}
+continue
+;;
+
-Z*)
if test os2 = "`expr $host : '.*\(os2\)'`"; then
# OS/2 uses -Zxxx to specify OS/2-specific options
--
2.5.2
Re: [PATCH] Re: libtool-2.4.2 is fine but libtool-2.4.6 very slow.
Hello Pavel. Thank you for your advice. Workaround worked perfectly!!. https://github.com/groonga/groonga/commit/7d7a62a2fba74334b23d0021a9a9e78da046b21c Thanks. 2015年9月19日(土) 17:09 Pavel Raiskup : > Hi Hiroyuki Sato, > > On Wednesday 02 of September 2015 16:00:34 Hiroyuki Sato wrote: > > This configure.ac is extreme slow on libtool-2.4.6. > > But It run smoothly on libtool-2.4.2. > > https://github.com/groonga/groonga/blob/master/configure.ac > > thanks for reproducer! > > This _really_ looks like issue mentioned [1], though the thread is > believed to be resolved (with existing small slowdown between > libtool-2.4.5 and 2.4.2). Let me CC Robert whether this patch does not > actually fix the "1 sec" slowdown of libtoolize. > > > Could you tell me how to fix this problem?. > > You can workaround/fix this by: > -m4_define([nginx_version], m4_include(nginx_version)) > -NGINX_VERSION=nginx_version > +NGINX_VERSION=m4_include([nginx_version]) > > See the "recursion" in 'nginx_version' definition. Its not recursion > usually (because nginx_version is not defined in the time of m4_define) > -- but libtoolize script does 'm4_undefine(m4_include)' before > evaluating configure.ac. > > > Is this libtool's Bug? > > I would say so, see the attached patch I'll push very soon (if there are > no objections). > > > * OS OSX 10.10.5. and CentOS7 > > Should be IMO reproducible everywhere. > > [1] http://lists.gnu.org/archive/html/libtool/2015-02/msg0.html > > Thanks, Pavel > -- > > > Thanks. > > > > libtool-2.4.6 > > > > time /tmp/libtool246/bin/libtoolize --verbose --copy --force > > libtoolize: found 'configure.ac' > > libtoolize: export M4='/usr/bin/gm4' > > > > It takes around 10 minutes. > > > > libtool-2.4.2 > > > > time /tmp/libtool242/bin/libtoolize --verbose --copy --force > > libtoolize: rm -f './ltmain.sh' > > libtoolize: putting auxiliary files in `.'. > > libtoolize: copying file from > `/tmp/libtool242/share/libtool/config/ltmain.sh' > > libtoolize: rm -f './libtool.m4' > > libtoolize: rm -f './ltoptions.m4' > > libtoolize: rm -f './ltsugar.m4' > > libtoolize: rm -f './ltversion.m4' > > libtoolize: rm -f './lt~obsolete.m4' > > libtoolize: Not copying `./argz.m4', libltdl not used. > > libtoolize: putting macros in `.'. > > libtoolize: copying file from > `/tmp/libtool242/share/aclocal/libtool.m4' > > libtoolize: Not copying `./ltdl.m4', libltdl not used. > > libtoolize: copying file from > `/tmp/libtool242/share/aclocal/ltoptions.m4' > > libtoolize: copying file from > `/tmp/libtool242/share/aclocal/ltsugar.m4' > > libtoolize: copying file from > `/tmp/libtool242/share/aclocal/ltversion.m4' > > libtoolize: copying file from > `/tmp/libtool242/share/aclocal/lt~obsolete.m4' > > libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to > configure.ac and > > libtoolize: rerunning libtoolize, to keep the correct libtool macros > in-tree. > > > > real 0m1.003s > > user 0m0.364s > > sys 0m0.540s > > > > > > >
