[patch #6448] [MSVC 7/7] Add MSVC Support

[Matthias Pleh]

Follow-up Comment #8, patch #6448 (project libtool):

Ok, I see. So we need a working version of cccl or a replacement. I try to
make a deeper look into this issue.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/

Re: discard “Configured with” line from gcc -v output

[Alexandre Oliva]

On Sep  8, 2009, Ralf Wildenhues  wrote:

> * Alexandre Oliva wrote on Tue, Sep 08, 2009 at 05:17:28PM CEST:

>> The symptom was an incomplete link command line, resulting from a
>> trailing «'» character in a -L flag added by libtool.

> FWIW, it is not clear to me why this shouldn't have hurt you earlier.

I was just as surprised.  I couldn't find any particular change that
would have exposed this latent problem.

It *could* be related with the upgrade to a newer autoconf in GCC, which
might in turn have started adding more variables to the config.status
--recofigure command line.

>> Here's what I'm going to installing in the GCC tree momentarily.  I
>> suggest libtool to adopt something along the same lines.

> The patch is not ok for upstream Libtool, which unfortunately also has
> to support other compilers that pretend to be GCC, but produce different
> '-v -shared' output (ICC and PathScale are in this boat IIRC).  ICC
> won't match your changed grep, I think.  Yes, it's ugly and they should
> be punished for being an imperfect impersonation, but that's not
> something you can tell users.

:-)

> Have you checked older GCC versions for the format?

Not really, although I'm pretty sure this leading whitespace oddity has
bugged me for a very long time.  But given the above, it shouldn't
really matter.

> One possibility would be to grep out "Configured with" lines.  I'll look
> into it.

That ought to work.  Thanks!

-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist  Red Hat Brazil Compiler Engineer

Re: discard “Configured with” line from gcc -v output

[Ralf Wildenhues]

Hello Alexandre,

thanks for the report.

* Alexandre Oliva wrote on Tue, Sep 08, 2009 at 05:17:28PM CEST:
> Since the latest libtool update in GCC, I've had problems building
> libstdc++-v3 on x86_64-linux-gnu.  The symptom was an incomplete link
> command line, resulting from a trailing «'» character in a -L flag added
> by libtool.

FWIW, it is not clear to me why this shouldn't have hurt you earlier.

> It turned out to be improperly auto-detected from the gcc -shared -v
> output.  The issue is that, after zero or perhaps more reconfigurations
> of the gcc top-level, the arguments passed to the gcc configure, and
> that are reported by gcc -v in the build tree, look like this:
[...]
> The attentive reader will notice the -L flag at the end of
> CXX_FOR_TARGET.  libtool.m4 is not clever enough to realize that the
> trailing «'» is just closing the one before CXX_FOR_TARGET, and to
> disregard the whole thing, so it takes the argument at face value, with
> a trailing apostrophe and all.  That doesn't quite work.

Yep.

> The fix I came up with was to avoid lines that didn't contain the
> information libtool was interested in.  It turns out that only lines
> started with blanks contain the actual commands line that GCC runs, so I
> narrowed the grep for -L flags to such lines.
> 
> Here's what I'm going to installing in the GCC tree momentarily.  I
> suggest libtool to adopt something along the same lines.

The patch is not ok for upstream Libtool, which unfortunately also has
to support other compilers that pretend to be GCC, but produce different
'-v -shared' output (ICC and PathScale are in this boat IIRC).  ICC
won't match your changed grep, I think.  Yes, it's ugly and they should
be punished for being an imperfect impersonation, but that's not
something you can tell users.

Have you checked older GCC versions for the format?

One possibility would be to grep out "Configured with" lines.  I'll look
into it.

Thanks,
Ralf

[patch #6448] [MSVC 7/7] Add MSVC Support

[Peter Rosin]

Follow-up Comment #7, patch #6448 (project libtool):

Hi Matthias!

Ok, I have tried that cccl script, but it still fails miserably to even build
libtool. So naturally I have no testsuite results. The failure looks the same
(on a cursory look) on master and on the pr-msvc-support branch so I do not
appear to have made things worse...

This cccl script is not targeting MSYS (it uses single forward slashes) and
can therefore only be used from cygwin. It is also a fact that this cccl
script uses cygpath to convert incoming posix paths to windows paths, which
libtool is also doing when cccl is detected on cygwin. That looks like a major
incompatibilty to me. The provided ccclibtool wrapper isn't improving things
for me.

I still need someone to show me a recipe for how to build libtool with (some
incarnation of) cccl.

Cheers,
Peter


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Re: Make -Wc,foo behave like -Xcompiler foo in link mode.

[Ralf Wildenhues]

Hi Peter,

* Peter Rosin wrote on Tue, Sep 08, 2009 at 09:44:46AM CEST:
> Den 2009-09-07 21:09 skrev Ralf Wildenhues:
> >>>+  eval "`$LIBTOOL --tag=$tag --config | $EGREP 
> >>>'^(wl|archive_cmds|reload_cmds)='`"
> >>You are not using $reload_cmds anywhere.
> >
> >Indeed; I added it because I thought of running a reload command, until
> >I realized that it wouldn't contain these flags anyway.  Removing it.
> >Thanks.
> 
> Still there :-)

D'oh.  Save before sending.  Thanks for checking!

> >Yeah, stresstest is ugly to debug.  I always run with -v -x to get as
> >many clues as possible.  But if you'd like to add more markers, feel
> >free to.

> Adding -x really helps, thanks for the hint! But it isn't really
> optimal when all commands seem to originate from line 24. E.g.

> ../../tests/flags.at:24: { test -n "$CC" && test "X$CC" != Xno; } || (exit 77)
> ../../tests/flags.at:24: $LIBTOOL --tag=CC --mode=compile $compile -c $source
> ../../tests/flags.at:24: $LIBTOOL -n --tag=CC --mode=compile $compile
> $flag-foo -c $source
> ../../tests/flags.at:24: $FGREP " -foo" stdout

Ouch.  Hmm, that's due to the m4_foreach construct.  I don't know how to
fix that, short of expanding the test into one for each tag.  Maybe
something can be done upstream at the Autotest level about this.

> But the test isn't that long so not a major problem.

OK.  Anyway, the -x output shows variables expanded, that should help to
see what the particular command was about.

> >Does it pass for you?
> 
> Yes. gcc-3.4/cygwin-1.5 and msvc/msys are both ok. At least after I
> apply my "-Wc,"-patch, didn't have that originally on the msvc branch
> which threw me off track for a while... So, I can report that the test
> only seems to catch the original bug if $wl is non-empty. Probably
> good enough though...

Well, if $wl is empty, then it would seem to me that it doesn't really
matter on this particular system whether libtool prepends that to flags
or not.  You can't really expect the testsuite to expose a system-
specific bug on every other system.  We can try to make tests as widely
exposing as possible, but we shouldn't do so beyond reasonable effort.

My idea of the ideal Libtool test suite is to get as many semantics
covered as possible for the system and compiler combination at hand,
and then before a release do regression tests on as many systems and
with as many compilers as possible, to then be reasonably sure that
we don't regress.  I don't see another realistic way.

Of course, things like tests for Darwin-specific bugs, where the test
happens to be pretty much system-agnostic, can only help if run on all
systems.

BTW, you are free to merge from master to pr-msvc-support (after testing
that the merged tree still works as desired, of course) when you like.
That can only help.

Thanks,
Ralf

Re: [PATCH] Allow dlopen self test to work with gcc's -fvisibility=hidden.

[Peter O'Gorman]

Ralf Wildenhues wrote:
> * Peter O'Gorman wrote on Mon, Sep 07, 2009 at 11:16:05PM CEST:
>> Ralf Wildenhues wrote:
>>
>>> No, it must have been earlier.  gcc-3.3 (Debian 3.3.6-15) accepts it,
>>> gcc-2.95.4 rejects it.
>> Ah, ok - this is it?
>>
>> 2002-11-26  Richard Henderson  
>>
>> * c-common.c (handle_visibility_attribute): Accept "default".
> 
> Yes, I think so.  That would indicate that 3.3 is the first version to
> have it, given the GCC timeline.  So, based on that, ok to apply this
> instead?
> 

Yes, thanks.

Peter
-- 
Peter O'Gorman
http://pogma.com

discard “Configured with” line from gcc -v output

[Alexandre Oliva]

Since the latest libtool update in GCC, I've had problems building
libstdc++-v3 on x86_64-linux-gnu.  The symptom was an incomplete link
command line, resulting from a trailing «'» character in a -L flag added
by libtool.

It turned out to be improperly auto-detected from the gcc -shared -v
output.  The issue is that, after zero or perhaps more reconfigurations
of the gcc top-level, the arguments passed to the gcc configure, and
that are reported by gcc -v in the build tree, look like this:

Configured with: ../configure --cache-file=./config.cache -C 
--prefix=/l/tmp/build/toolchains/x86_64-linux-gnu --enable-checking 
--enable-shared --enable-threads=posix --enable-__cxa_atexit 
--disable-libunwind-exceptions --enable-java-awt-but=gtk --disable-dssi 
--enable-plugin-but --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre 
--enable-libgcj-multifile --disable-java-maintainer-mode 
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-cpu=generic CC='ccache 
gcc -fno-working-directory -m64' CXX='ccache g++ -fno-working-directory -m64' 
CCC='ccache g++ -fno-working-directory -m64' 
target_alias=x86_64-unknown-linux-gnu CFLAGS='-g -O2' LDFLAGS= CXXFLAGS='-g 
-O2' 'CC_FOR_TARGET=distccrel 
/l/tmp/build/gcc/trunk/obj-x86_64-linux-gnu/./gcc/xgcc 
-B/l/tmp/build/gcc/trunk/obj-x86_64-linux-gnu/./gcc/' 'CXX_FOR_TARGET=distccrel 
/l/tmp/build/gcc/trunk/obj-x86_64-linux-gnu/./gcc/g++ 
-B/l/tmp/build/gcc/trunk/obj-x86_64-linux-gnu/./gcc/ -nostdinc++  
-L/l/tmp/build/gcc/trunk/obj-x86_64-linux-gnu/x86_64-unknown-linux-gnu/libstdc++-v3/src
 
-L/l/tmp/build/gcc/trunk/obj-x86_64-linux-gnu/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs'
 'GCJ_FOR_TARGET=distccrel 
/l/tmp/build/gcc/trunk/obj-x86_64-linux-gnu/./gcc/gcj 
-B/l/tmp/build/gcc/trunk/obj-x86_64-linux-gnu/./gcc/' 
'GFORTRAN_FOR_TARGET=distccrel 
/l/tmp/build/gcc/trunk/obj-x86_64-linux-gnu/./gcc/gfortran 
-B/l/tmp/build/gcc/trunk/obj-x86_64-linux-gnu/./gcc/' AR_FOR_TARGET=ar 
AS_FOR_TARGET=as DLLTOOL_FOR_TARGET=dlltool LD_FOR_TARGET=ld 
LIPO_FOR_TARGET=lipo NM_FOR_TARGET=nm OBJDUMP_FOR_TARGET=objdump 
RANLIB_FOR_TARGET=ranlib STRIP_FOR_TARGET=strip WINDRES_FOR_TARGET=windres 
WINDMC_FOR_TARGET=windmc --enable-languages=c,ada,c++,fortran,java,objc 
--no-create --no-recursion

The attentive reader will notice the -L flag at the end of
CXX_FOR_TARGET.  libtool.m4 is not clever enough to realize that the
trailing «'» is just closing the one before CXX_FOR_TARGET, and to
disregard the whole thing, so it takes the argument at face value, with
a trailing apostrophe and all.  That doesn't quite work.

The fix I came up with was to avoid lines that didn't contain the
information libtool was interested in.  It turns out that only lines
started with blanks contain the actual commands line that GCC runs, so I
narrowed the grep for -L flags to such lines.

Here's what I'm going to installing in the GCC tree momentarily.  I
suggest libtool to adopt something along the same lines.

for  ChangeLog
from  Alexandre Oliva  

	* libtool.m4 (output_verbose_link_cmd): Require leading blank, and
	blank before -L.
	
for  gcc/ChangeLog
from  Alexandre Oliva  

	* configure: Rebuilt with modified libtool.m4.

for  libstdc++-v3/ChangeLog
from  Alexandre Oliva  

	* configure: Rebuilt with modified libtool.m4.

for  boehm-gc/ChangeLog
from  Alexandre Oliva  

	* configure: Rebuilt with modified libtool.m4.

for  libjava/ChangeLog
from  Alexandre Oliva  

	* configure: Rebuilt with modified libtool.m4.

Index: libtool.m4
===
--- libtool.m4.orig	2009-09-07 04:31:45.0 -0300
+++ libtool.m4	2009-09-07 04:33:09.0 -0300
@@ -5471,7 +5471,7 @@ if test "$_lt_caught_CXX_error" != yes; 
   # Commands to make compiler produce verbose output that lists
   # what "hidden" libraries, object files and flags are used when
   # linking a shared library.
-  output_verbose_link_cmd='$CC -shared $CFLAGS -v conftest.$objext 2>&1 | $GREP "\-L"'
+  output_verbose_link_cmd='$CC -shared $CFLAGS -v conftest.$objext 2>&1 | $GREP "^ .* -L"'
 
 else
   GXX=no
@@ -5716,7 +5716,7 @@ if test "$_lt_caught_CXX_error" != yes; 
 # explicitly linking system object files so we need to strip them
 # from the output so that they don't get included in the library
 # dependencies.
-output_verbose_link_cmd='templist=`($CC -b $CFLAGS -v conftest.$objext 2>&1) | $EGREP "\-L"`; list=""; for z in $templist; do case $z in conftest.$objext) list="$list $z";; *.$objext);; *) list="$list $z";;esac; done; $ECHO "X$list" | $Xsed'
+output_verbose_link_cmd='templist=`($CC -b $CFLAGS -v conftest.$objext 2>&1) | $GREP "^ .* -L"`; list=""; for z in $templist; do case $z in conftest.$objext) list="$list $z";; *.$objext);; *) list="$list $z";;esac; done; $ECHO "X$list" | $Xsed'
 ;;
   *)
 if test "$GXX" = yes; then
@@ -5781,7 +5781,7 @@ if test "$_lt_c

[patch #6448] [MSVC 7/7] Add MSVC Support

[Matthias Pleh]

Follow-up Comment #6, patch #6448 (project libtool):

Peter, you have mentioned, that you wanted to test this path with cccl, but
doesn't worked for you. I don't know if this is still an issue but there
exists a new patch for cccl mentioned on this site:
http://folti.blogs.balabit.com/2009/08/compiling-autoconfmake-using-sources.html
source code can be downloaded from 
$ git clone git://git.balabit.hu/folti/cccl.git

I hope this helps to improve the MSVC support, because for now this is a must
have to introduce the use of open source libraries in our company!

Cheers,
Matthias



___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/

Re: Make -Wc,foo behave like -Xcompiler foo in link mode.

[Peter Rosin]

Den 2009-09-07 21:09 skrev Ralf Wildenhues:

+  eval "`$LIBTOOL --tag=$tag --config | $EGREP 
'^(wl|archive_cmds|reload_cmds)='`"

You are not using $reload_cmds anywhere.


Indeed; I added it because I thought of running a reload command, until
I realized that it wouldn't contain these flags anyway.  Removing it.
Thanks.


Still there :-)


[...]

+done
+  done
+done
+
+AT_CLEANUP

There needs to be some markers about what is being done when
there is a repetetive loop like this (48 times through the
innermost loop in the "worst case"). I remember hardship
trying to deduce exactly what failed when I had a failure
inside stresstest.at...


Yeah, stresstest is ugly to debug.  I always run with -v -x to get as
many clues as possible.  But if you'd like to add more markers, feel
free to.


An example: If the following line fails, the test as written
doesn't give too many hints as to what it's trying to do:

../../tests/flags.at:89: $LIBTOOL -n --tag=$tag --mode=link $link  
-o $output a.lo -rpath /nowhere $flag-foo

Maybe it's as simple as using LT_AT_CHECK instead of AT_CHECK?


Well, the following already splits it up into four tests with 12
commands each.  Maybe that is enough to make it feasible?


Adding -x really helps, thanks for the hint! But it isn't really
optimal when all commands seem to originate from line 24. E.g.

../../tests/flags.at:24: { test -n "$CC" && test "X$CC" != Xno; } || (exit 77)
../../tests/flags.at:24: $LIBTOOL --tag=CC --mode=compile $compile -c $source
../../tests/flags.at:24: $LIBTOOL -n --tag=CC --mode=compile $compile
$flag-foo -c $source
../../tests/flags.at:24: $FGREP " -foo" stdout
../../tests/flags.at:24: $LIBTOOL -n --tag=CC --mode=link $link  -o 
$output a.lo -rpath /nowhere $flag-foo

But the test isn't that long so not a major problem.


Does it pass for you?


Yes. gcc-3.4/cygwin-1.5 and msvc/msys are both ok. At least after I
apply my "-Wc,"-patch, didn't have that originally on the msvc branch
which threw me off track for a while... So, I can report that the test
only seems to catch the original bug if $wl is non-empty. Probably
good enough though...

Cheers,
Peter