e should check and maintain the whole libtool.m4
> file?!
>
> kind regards
> christian
I filed https://savannah.gnu.org/support/index.php?108987 a few months ago,
are you saying the proposed patches don't fix this?
--
Richard PALO
use as documented, that is to respect the environment
if these variables
are set, but naturally -- if set -- they will be just the path to the tool and
as such can in no
way expect that '-f' is specified (which is '--force' under the Gnu flavours of
these tools).
--
Richard PALO
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 <bvanass...@acm.org> wrote:
>>> This behavior has been observed with libtool version 2.2.6.
>>
>> Bug conf
Le 09/11/13 07:44, Richard PALO a écrit :
I believe Chuck is oriented in the right direction.
A good example is with -fstack-protector.
gcc/g++ knows how to link depending upon whether the platforms libc has
SSP support or not.
I doubt very much that libtool wants to figure out whether to add
Le 17/01/14 15:02, Rainer Orth a écrit :
As reported in
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16452
the default for opt_duplicate_compiler_generated_deps can cause
exception handling/unwinding failures on 64-bit Solaris 10+/x86 when the
underlying gcc bug
Le 08/11/13 20:07, Charles Wilson a écrit :
On 11/8/2013 1:49 PM, Bob Friesenhahn wrote:
Isn't it because libtool wants to control the order of the linking and
assure that all dependencies (including static) are tracked/known and
applied at the correct times? It wants to assure that static
Le 02/06/10 05:24, Yaakov (Cygwin/X) a écrit :
On Sat, 15 May 2010 09:07:49 +0200
Bart Van Assche bvanass...@acm.org 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
