Re: [PATCH, take 5][cygwin|mingw] Control where win32 DLLs get installed.

2009-09-12 Thread Ralf Wildenhues
[ http://thread.gmane.org/gmane.comp.gnu.libtool.patches/9412 ]

Hi Dave,

* Dave Korn wrote on Mon, Aug 17, 2009 at 07:25:04AM CEST:
 libtool/ChangeLog:
 
   * Makefile.am (TESTSUITE_AT): Add bindir.at.
   * libltdl/config/general.m4sh (func_normal_abspath): New function.
   (func_relative_path): Likewise.
   * libltdl/config/ltmain.m4sh (func_mode_help): Document -bindir.
   (func_mode_link): Accept new -bindir option and use it, if
   supplied, to place Windows DLLs.
   * tests/bindir.at: New file for install tests using -bindir.
   * doc/libtool.texi (Link Mode): Update documentation.
 
   Built and tested on i686-pc-cygwin and i686-pc-linux-gnu with no regressions
 and all new tests passing.  Ok now?

I've pushed that patch now, adding you to THANKS, removing some trailing
whitespace from your patch, and including the diff below that also has
some fixes found in GCC.

Thanks again,
Ralf

Control where win32 DLLs get installed.

* libltdl/config/general.m4sh (func_normal_abspath): New function.
(func_relative_path): Likewise.
* libltdl/config/ltmain.m4sh (func_mode_help): Document -bindir.
(func_mode_link): Accept new -bindir option and use it, if
supplied, to place Windows DLLs.
* tests/bindir.at: New file for install tests using -bindir.
* Makefile.am (TESTSUITE_AT): Add bindir.at.
* doc/libtool.texi (Link Mode): Update documentation.
* NEWS, THANKS: Update.

diff --git a/NEWS b/NEWS
index c7d3016..f96a717 100644
--- a/NEWS
+++ b/NEWS
@@ -15,6 +15,7 @@ New in 2.2.8 2009-??-??: git version 2.2.7a, Libtool team:
   - New convenience make targets `check-noninteractive' to avoid long testsuite
 runs on Windows with popup windows in the middle, and `check-interactive'
 for the complement set of tests.
+  - New link mode flag -bindir to specify the location for installed PE DLLs.
 
 * Changes in supported systems or compilers:
 
diff --git a/libltdl/config/general.m4sh b/libltdl/config/general.m4sh
index c751629..53fafba 100644
--- a/libltdl/config/general.m4sh
+++ b/libltdl/config/general.m4sh
@@ -103,8 +103,8 @@ func_dirname_and_basename ()
 # These SED scripts presuppose an absolute path with a trailing slash.
 pathcar=s,^/\([^/]*\).*$,\1,
 pathcdr=s,^/[^/]*,,
-removedotparts=s,/\(\./\)\{1\,\},/,g;s,/\.$,/,
-collapseslashes=s,/\{1\,\},/,g
+removedotparts=s@/\(\./\)\{1,\}@/@g;s,/\.$,/,
+collapseslashes=s@/\{1,\}@/@g
 finalslash=s,/*$,/,
 
 # func_normal_abspath PATH
diff --git a/tests/bindir.at b/tests/bindir.at
index c736799..74a7ced 100644
--- a/tests/bindir.at
+++ b/tests/bindir.at
@@ -67,7 +67,7 @@ AT_DATA([simple.c] ,[[
 int main() { return 0;}
 ]])
 
-$CC $CPPFLAGS $CFLAGS -o simple simple.c 21  /dev/null || noskip=false
+$CC $CPPFLAGS $CFLAGS -o simple simple.c || noskip=false
 rm -f simple
 
 AT_CHECK([$noskip || (exit 77)])




Re: pr-msvc-support: building .DLLs with symbols

2009-09-12 Thread Peter Rosin

Hi David,

Thanks for testing!

Den 2009-09-11 21:04 skrev David Byron:

Here's a couple of patches that implements support for
-Wl, and -Xlinker for MSVC. The first one
(rename-dashL_envvar-tolinker_envvar.patch) is just a
rename, to reduce confusion, and the second patch
(-Xlinker-msvc.patch) contains the new code...

Ok for the pr-msvc-support branch?


I'm not sure I'm exercising the patch properly, but here's what I did:

- applied the patch

$ patch -p1 rename-dashL_envvar-tolinker_envvar.patch
$ patch -p1 -Xlinker-msvc.patch

- re-built libtool

$ cd build
$ make
$ make install

Then in one of my modules:

$ autoreconf -fvi
$ mkdir Debug
$ cd Debug
$ ../configure CC=cl CFLAGS='-MD -Zi' LD=link NM='dumpbin -symbols' AR=lib
STRIP=: RANLIB=: --disable-static

So far so good.  But, 


$ ../configure CC=cl CFLAGS='-MD -Zi' LD=link LDFLAGS='-Wl,-DEBUG'
NM='dumpbin -symbols' AR=lib STRIP=: RANLIB=: --disable-static


That will not work (as you noticed) as it will send the -Wl, option
stright to cl when configure tries w/o libtool.


checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... cl
checking for C compiler default output file name...
configure: error: in `abs_path_to/build':
configure: error: C compiler cannot create executables
See `config.log' for more details.

and config.log has:

configure:2791: checking for C compiler default output file name
configure:2813: cl -MD -Zi  -Wl,-DEBUG conftest.c  5
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for
80x86 Copyright (C) Microsoft Corporation.  All rights reserved.  cl :
Command line error D8021 : invalid numeric argument '/Wl,-DEBUG'
configure:2817: $? = 2
configure:2855: result: 
configure: failed program was:

| /* confdefs.h.  */
| #define PACKAGE_NAME foo
| #define PACKAGE_TARNAME foo
| #define PACKAGE_VERSION 1.0
| #define PACKAGE_STRING foo 1.0
| #define PACKAGE_BUGREPORT 
| #define PACKAGE foo
| #define VERSION 1.0
| /* end confdefs.h.  */
| 
| int

| main ()
| {
| 
|   ;

|   return 0;
| }
configure:2861: error: in
`/c/utils/cygwin/home/dbyron/src/ams_svn/AMS_SDK/trunk/final_review/build':
configure:2864: error: C compiler cannot create executables

If I go back to the working configure invocation, but change my Makefile.am
with:

libfoo_la_LDFLAGS += -Wl,-DEBUG

The resulting library doesn't contain debug symbols.  Here's the libtool
invocation that creates the library:


*snip*


Should I be doing something else?


Probably, works for metm. Maybe your autoreconf didn't really take for some
reason? (I haven't worked too much with autoreconf, and don't really know what
to expect from it)

Linking a program:

$ echo int main(void) { return 0; }  main.c
$ ./libtool --tag=CC --mode=link cl -o main main.c -Wl,-DEBUG
libtool: link: LINK= -DEBUG  cl -o .libs/main main.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

cl : Command line warning D9035 : option 'o' has been deprecated and will be 
removed in a future release
main.c
Microsoft (R) Incremental Linker Version 8.00.50727.762
Copyright (C) Microsoft Corporation.  All rights reserved.

-DEBUG
/out:main.exe
/out:.libs/main.exe
main.obj
libtool: link: lt_outputfile=.libs/main
libtool: link:  case .libs/main in *.[eE][xX][eE]) ;; *) 
lt_outputfile=.libs/main.exe ;; esac
libtool: link:  if test -e .libs/main.exe.manifest; then mt -manifest 
.libs/main.exe.manifest -outputresource:.libs/main.exe || exit 1; rm -f .libs/main.
exe.manifest; fi
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 80x86

Copyright (C) Microsoft Corporation.  All rights reserved.

cl : Command line warning D9035 : option 'o' has been deprecated and will be 
removed in a future release
lt-main.c
Microsoft (R) Incremental Linker Version 8.00.50727.762
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:lt-main.exe
/debug
/out:./main.exe
lt-main.obj


Linking a library:

$ echo int foo(void) { return 0; }  foo.c
$ ./libtool --tag=CC --mode=compile ../libltdl/config/compile cl -o foo.lo -c 
foo.c
libtool: compile:  ../libltdl/config/compile cl -c -TC foo.c  -DDLL_EXPORT 
-DPIC -o .libs/foo.obj
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

foo.c
libtool: compile:  ../libltdl/config/compile cl -c -TC foo.c -o foo.obj /dev/null 
21
$ ./libtool --tag=CC --mode=link ../libltdl/config/compile cl -o libfoo.la 
foo.lo -Wl,-DEBUG -no-undefined -rpath /nowhere
libtool: link: rm -fr  .libs/foo.exp .libs/foo.lib .libs/libfoo.la
libtool: link: dumpbin -symbols  .libs/foo.obj   | gawk ' {last_section=section; section=$ 3}; /Section length .*#relocs.*(pick any)/{hide[last_section]=1}; $ 

RE: pr-msvc-support: building .DLLs with symbols

2009-09-12 Thread David Byron
  $ ../configure CC=cl CFLAGS='-MD -Zi' LD=link LDFLAGS='-Wl,-DEBUG'
  NM='dumpbin -symbols' AR=lib STRIP=: RANLIB=: --disable-static

 That will not work (as you noticed) as it will send the -Wl, option
 stright to cl when configure tries w/o libtool.

Is there any hope of this working one day?  What would it take?  I suppose
this is an autoconf issue, not a libtool one but am I wrong in thinking that
in some more complete sense of msvc support that it should work?
 
  If I go back to the working configure invocation, but 
 change my Makefile.am
  with:
  
  libfoo_la_LDFLAGS += -Wl,-DEBUG
  
  The resulting library doesn't contain debug symbols.  
  Here's the libtool invocation that creates the library:
 
 *snip*
 
  Should I be doing something else?
 
 Probably, works for metm. Maybe your autoreconf didn't
 really take for some reason? (I haven't worked too much
 with autoreconf, and don't really know what to expect from
 it)

I blew away all the stuff related to autoreconf and re-ran it and now it
works.  If someone is interested in figuring out more about what's going on
here, let me know and I'll revert the patches and re-test, etc.

 Linking a program:
 
 $ echo int main(void) { return 0; }  main.c
 $ ./libtool --tag=CC --mode=link cl -o main main.c -Wl,-DEBUG

This works.

 Linking a library:
 
 $ echo int foo(void) { return 0; }  foo.c
 $ ./libtool --tag=CC --mode=compile ../libltdl/config/compile 
 cl -o foo.lo -c foo.c
 $ ./libtool --tag=CC --mode=link ../libltdl/config/compile cl 
 -o libfoo.la foo.lo -Wl,-DEBUG -no-undefined -rpath /nowhere

So does this.

Thanks for your help.

-DB