date:20060221

Re: HEAD: static tests

2006-02-21 Thread Ralf Wildenhues

* Ralf Wildenhues wrote on Mon, Jan 30, 2006 at 10:29:33PM CET:
 * Ralf Wildenhues wrote on Mon, Jan 30, 2006 at 02:01:53PM CET:
  
  I will followup to this mail (to libtool-patches only for size) with a
  patch to implement per-deplib flags for programs (for CVS HEAD) and add
  comprehensive tests for the static flags.
 
 Here goes the test.  Note that the tests uncovered that hardcoding
 was not done in all cases where necessary with the `-static' flag
 since we changed its behavior; a fix will be proposed in a followup.

Small update to the proposed patch: if link_static_flag is empty, don't
expect `-all-static' to do wonders magically.  Add keyword, remove some
cruft leftover from testing.

I intend to apply as one patch.  If ok..

Cheers,
Ralf

   * tests/static.at: New tests for comprehensive test exposure of
   all current and proposed static linking flags for programs.
   * Makefile.am, tests/testsuite.at: Updated.


--- tests/static.at 2006-02-21 08:29:17.0 +0100
+++ tests/static.at 2006-02-03 10:14:52.0 +0100
@@ -63,6 +63,7 @@
 #   (most likely the Sun compiler suite will be the only problem child).
 
 AT_SETUP([static linking flags for programs])
+AT_KEYWORDS([libtool])
 
 LDFLAGS=$LDFLAGS -no-undefined
 prefix=`pwd`/inst
@@ -207,7 +227,7 @@
   # global static flags.
   for st in -static -static-libtool-libs -all-static; do
 AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS $st -o m$st m.$OBJEXT \
- -L${libdir}1 $R -la1 a2/liba2.la -L${libdir}3 -R${libdir}3 -la3],
+ -L${libdir}1 -la1 a2/liba2.la -L${libdir}3 -R${libdir}3 -la3],
 [0], [ignore], [ignore])
   done
 
@@ -270,21 +292,26 @@
   # - remove the library images to catch failure to link 
statically/dynamically,
   # - add false other deplibs in the paths to catch (some) wrongly added run 
paths.
 
+  # if -all-static does not work, do not exercise it any more.
+  all_static=-all-static
+  eval `$LIBTOOL --config | grep '^link_static_flag='`
+  test -z $link_static_flag  all_static=
+
   echo ### test whether installed libtool library liba2 was linked statically
   func_move_libs a2 ${libdir}2
-  func_test_exec -static -static-libtool-libs -all-static `$per_deplib  echo 
2 12 23 123 123a`
+  func_test_exec -static -static-libtool-libs $all_static `$per_deplib  echo 
2 12 23 123 123a`
   $per_deplib  func_test_exec_fail 1 3 13 31
   func_restore_libs a2 ${libdir}2
 
   echo ### test whether uninstalled libtool library liba1 was linked 
statically
   func_move_libs a1 ${libdir}1
-  func_test_exec -static-libtool-libs -all-static `$per_deplib  echo 1 12 13 
31 123 123a`
+  func_test_exec -static-libtool-libs $all_static `$per_deplib  echo 1 12 13 
31 123 123a`
   $per_deplib  func_test_exec_fail -static 2 3 23
   func_restore_libs a1 ${libdir}1
 
   echo ### test whether non-libtool library liba3 was linked statically
   func_move_libs a3 ${libdir}3
-  func_test_exec -all-static `$per_deplib  echo 3 13 23 31 123 123a`
+  func_test_exec $all_static `$per_deplib  echo 3 13 23 31 123 123a`
   func_test_exec_fail -static -static-libtool-libs `$per_deplib  echo 1 2 12`
   func_restore_libs a3 ${libdir}3

some pending patches (was: document some more libtool variables)

2006-02-21 Thread Ralf Wildenhues

Hi Gary,

* Gary V. Vaughan wrote on Tue, Feb 21, 2006 at 01:21:33AM CET:
 Ralf Wildenhues wrote:
 
  BTW, should I wait for a review to install any of these patches?

 I didn't see these go by :-(  Urk, I hope my spam filter isn't getting
 false positives :'(

Here's the list with URLs added:

- patch adding -static-libtool-libs

http://article.gmane.org/gmane.comp.gnu.libtool.patches/6715

- patch adding tests/static.at (depends upon former)

http://article.gmane.org/gmane.comp.gnu.libtool.patches/6728
I have an update to that patch which I will post promptly.

- patch fixing the locking issue with compiler_c_o=no

http://article.gmane.org/gmane.comp.gnu.libtool.patches/6789

Cheers,
Ralf

Re: PGI Compiler patch for cygwin

2006-02-21 Thread Christopher Hulbert

On 2/21/06, Ralf Wildenhues [EMAIL PROTECTED] wrote:
 Hi Christopher,

 * Christopher Hulbert wrote on Tue, Feb 21, 2006 at 03:15:42PM CET:
  Attached is the test outputs.

 Thanks.  Unfortunately, I was not precise enough:
 Please configure Libtool with the Portland compilers, so that they are
 tested.  E.g., like
   ./configure CC=pgcc CXX=pgCC F77=pgf77 FC=pgf95

duh, I feel braindead :)!


 Sorry about that.  :-(

 Please note that the tarball you sent did not contain
 tests/testsuite.log.  It appears make_check_local was misplaced: there
 is a duplicate, packed copy of make_check in there.  It'd be great if
 you could send the testsuite.log file as well, and the other output with
 the above configuration.

Yeah, got an error that I couldn't append to a compressed tar archive
so that didn't make it :/.  Not that it mattered since I used the
wrong C compiler.


 But also see below:

  I looked at the failure for fcdemo.  It
  looks like autoconf's AC_FC_LIBRARY_LDFLAGS is not picking up the PGI
  libraries because they are wrapped in single quotes, i.e.
  '-Lc:\Program Files\PGI/nt86/6.0/lib'.

 Hmpf.  That'll be difficult to get both fixed in _AC_PROG_FC_V_OUTPUT
 and also all the way through Autoconf and Libtool so the embedded space
 isn't killed (or the path broken in two arguments).

Not sure what's going on here.  I use the AC_FC_LIBRARY_LDFLAGS in my
configure.ac and I don't get that problem.  libtool's configure must
be quoting each of these arguments??? I should note that I had to
patch fortran.m4 (a long time ago) to handle a case where the library
was butted up against a single quote such as 'blah blah -lm'.  I
thought I sent that info to the autoconf list a while ago???


 Probably it would currently be best (for Fortran users) to
 - either install the compiler under a path not containing spaces, or
 - create a config.site file for this compiler/system combination, with
   ac_cv_fc_libs pre-seeded with the right flags for Fortran, and
   alternate non-space path representations; on your system, that would
   be something like

 ac_cv_fc_libs='-Lc:/Progra~1/PGI/nt86/6.0/mingw/lib 
 -Lc:/Progra~1/PGI/nt86/6.0/mingw/mingw32/lib 
 -Lc:/Progra~1/PGI/nt86/6.0/mingw/lib/gcc-lib/mingw32/2.95.3-5 
 -Lc:/Progra~1/PGI/nt86/6.0/lib -lpgf90 -lpgf90_rpm1 -lpgf902 -lpgf90rtl 
 -lpgftnrtl -lpgc -lmingw32 -lgcc -lmoldname -lmsvcrt -luser32 -lkernel32 
 -ladvapi32 -lshell32'

   all on one line.  See the Autoconf docs for config.site files.
 - Or do both of the above.

 Also I think we need to stick `-Mnomain' in Fortran archive_cmds
 otherwise fcdemo will fail again.

Well, that depends on how you link.  I link my C code against the
archived fortran code separately so without forcing automake to use
LD=$(FC), it uses the C compiler, so I don't need -Mnomain (hence the
use of AC_FC_LIBRARY_LDFLAGS).


 Cheers,
 Ralf

  On 2/18/06, Ralf Wildenhues [EMAIL PROTECTED] wrote:
  
   The patch is ok, could you be bothered to run the testsuite once,
   verbosely
 make check VERBOSE=x TESTSUITE_FLAGS=-V
 make check-local
  
   and send (packed) the output and tests/testsuite.log, so we could hash
   out any other simple issues for decent support?

Re: PGI Compiler patch for cygwin

2006-02-21 Thread Christopher Hulbert

On 2/21/06, Ralf Wildenhues [EMAIL PROTECTED] wrote:
 Hi Christopher,

 * Christopher Hulbert wrote on Tue, Feb 21, 2006 at 05:48:56PM CET:
  I get this error compiling libtool.  It looks like it's trying to
  extract the symbols from libltdl/.libs/libltdl.lax/loadlibrary.lib,
  but the symbols look like they have paths associated with it and thus
  can't extract them because the path doesn't exist.  I guess this is
  because the library is created using pgcc which uses the MS hack for
  an archiver (lib).  Any ideas?

 Ah, ok.  At this point we need a feature of the pending patches from
 Peter Ekberg:
 http://article.gmane.org/gmane.comp.sysutils.automake.general/6539
 (but also see the part of this thread
 http://thread.gmane.org/gmane.comp.gnu.libtool.general/7182 that starts
 with 'msvs support' (sic)).

It seems the patch is no longer available.  The link refers to
6539-001.bin which doesn't exist.  Doing a directory listing lists
only 6539 and nothing else related to the thread.


 When that is applied, you will be able to configure with AR=link -lib
 or AR=lib and get the desired functionality.

 If someone (hint, hint) can get GNU binutils ar to do the one-by-one
 extraction nicely, or find some other nice way to achieve the
 extraction, I would not mind either.. I guess one way could be to
 collect the dirnames of all members from `ar t' and func_mkdir_p them..
 or a nice subset of that.. then actually extract all members..
 Sorry, I was thinking out loud.

 Cheers,
 Ralf

  /bin/sh ./libtool --tag=CC --mode=link pgcc  -g -no-undefined  -o
  libltdl/libltdl.la -rpath /usr/local/lib -no-undefined -version-info
 *snip*

  libtool: link: (cd libltdl/.libs/libltdl.lax/loadlibrary.lib  ar x
  /cygdrive/c/cygwin/home/chulbert/libtool-build/libltdl/.libs/loadlibrary.lib)
  libltdl/loaders/.libs/loadlibrary.o: No such file or directory

  bash-3.00$ lib -list libltdl/.libs/loadlibrary.lib
  Microsoft (R) Library Manager Version 7.10.3077
  Copyright (C) Microsoft Corporation.  All rights reserved.
 
  libltdl/loaders/.libs/loadlibrary.o
 
  bash-3.00$ ar t libltdl/.libs/loadlibrary.lib
  libltdl/loaders/.libs/loadlibrary.o

Re: fix the locking issue

2006-02-21 Thread Gary V. Vaughan

Hallo Ralf,

Ralf Wildenhues wrote:
 It is just intricate.  I'm don't mind a merge after 2.0, but if you deem
 it ok, I'd put it in CVS HEAD now.

Well, locks are just plain broken right now... and surely need to be
integrated more carefully with automake/autoconf in due course... but,
I trust your testing has already proven that this patch improves our
current situation somewhat, so I think it is safe to merge now.  Note
that I haven't performed any testing of my own on this patch (which I
had intended to do before I commented, and is how it got lost in my
mail archive).

 Notes:
 - The creation of the .libs/LoCk_SrC file may cause spurious errors on
   w32 systems, thus the drop of stderr.
 - We cannot remove the .libs/LoCk_SrC file in compile mode: that could
   defeat another libtool process concurrently running.  For the same
   reason, it does not make sense to put the object file name in its
   _name_.
 - Not creating the bugger in dry mode is necessary for mdemo-dryrun to
   succeed.
 - Testing for its existence in clean mode before removing is a hack,
   and won't save us in case the user is strange enough to do a parallel
   clean with `rm' as opposed to `rm -f'.  The fact that it is removed on
   the command line of the first object may seem a bit strange, however I
   could not see a good reason to add more special code for this.
 - If the user actually passes a non-existing object file `foo.lo' as the
   first one for this directory, then the `LoCk_SrC' file will not be
   removed.
 - Surely it breaks for a 'libtool --mode=clean' concurrently with a
   'libtool --mode=compile'.  Some sanity has to be expected from the user.
 - If any program has name `LoCk_SrC' and needs to be relinked upon
   execution, things break horribly.

Please try to work these items in as comments at appropriate places in
the code.  Where impractical, adding them to the ChangeLog entry is okay.

 Unfixed issue (which I don't intend to attack now):
 
 - need_locks is not tagged ATM.  It should not be (compiler_c_o already
   is), but tests for later tags should not be able to set it to NO, if
   earlier ones set it to something else.
 
 - putting the object file name in the _contents_ of the lock file is
   wrong, too, but AFAICS harmless, so it will be fixed later.

These too :-)

   * libltdl/config/ltmain.m4sh (func_mode_compile): When locking
   is necessary, hard-link against `.libs/lock_src' instead of
   `$progpath'.
   (func_mode_uninstall): In clean mode, remove `LoCk_SrC' if
   present, along with the first object we remove.
   Fixes potential hang reported by Marcin Siennicki and others.

Cheers,
Gary.
-- 
Gary V. Vaughan  ())_.  [EMAIL PROTECTED],gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker   / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook



signature.asc
Description: OpenPGP digital signature

Re: PGI Compiler patch for cygwin

2006-02-21 Thread Christopher Hulbert

On 2/21/06, Ralf Wildenhues [EMAIL PROTECTED] wrote:
 * Christopher Hulbert wrote on Tue, Feb 21, 2006 at 07:18:17PM CET:
  On 2/21/06, Ralf Wildenhues [EMAIL PROTECTED] wrote:

   http://article.gmane.org/gmane.comp.sysutils.automake.general/6539

  It seems the patch is no longer available.  The link refers to
  6539-001.bin which doesn't exist.  Doing a directory listing lists
  only 6539 and nothing else related to the thread.

 :-(  I did not know gmane expires attachments or hides them.
 This is the same article:
 http://lists.gnu.org/archive/html/libtool-patches/2005-11/msg00190.html

 Cheers,
 Ralf


I guess I should have replied syaing I checked that (after posting). 
I applied the patch but unfortunately some Hunks failed so I'm
applying them by hand and testing them.  For reference, here is the
output of patch.  Some of the failures are likely due to my PGI
changes.

bash-3.00$ patch -p0  ~/head-msys_msvc-13.patch
patching file Makefile.am
Hunk #1 succeeded at 406 (offset 28 lines).
patching file libltdl/config/ltmain.m4sh
Hunk #1 succeeded at 714 (offset 11 lines).
Hunk #2 FAILED at 1054.
Hunk #3 succeeded at 1355 (offset 35 lines).
Hunk #4 succeeded at 2683 (offset 35 lines).
Hunk #5 succeeded at 4170 (offset 43 lines).
Hunk #6 succeeded at 4765 (offset 40 lines).
Hunk #7 succeeded at 4794 (offset 40 lines).
Hunk #8 succeeded at 5392 (offset 68 lines).
Hunk #9 succeeded at 5626 with fuzz 2 (offset 99 lines).
Hunk #10 succeeded at 5933 (offset 99 lines).
Hunk #11 succeeded at 5989 (offset 99 lines).
Hunk #12 succeeded at 6096 (offset 99 lines).
Hunk #13 succeeded at 6274 (offset 99 lines).
Hunk #14 succeeded at 6567 (offset 113 lines).
1 out of 14 hunks FAILED -- saving rejects to file
libltdl/config/ltmain.m4sh.rej
patching file libltdl/m4/libtool.m4
Hunk #1 succeeded at 1209 (offset 7 lines).
Hunk #2 succeeded at 1271 (offset 7 lines).
Hunk #3 succeeded at 2108 (offset 13 lines).
Hunk #4 succeeded at 3027 (offset 39 lines).
Hunk #5 succeeded at 3045 (offset 39 lines).
Hunk #6 succeeded at 4026 (offset 84 lines).
Hunk #7 succeeded at 4137 (offset 88 lines).
Hunk #8 succeeded at 4330 (offset 103 lines).
Hunk #9 FAILED at 4458.
Hunk #10 FAILED at 4484.
Hunk #11 succeeded at 5094 (offset 131 lines).
Hunk #12 FAILED at 5470.
Hunk #13 succeeded at 5497 with fuzz 2 (offset 132 lines).
Hunk #14 succeeded at 5874 (offset 143 lines).
3 out of 14 hunks FAILED -- saving rejects to file libltdl/m4/libtool.m4.rej
patching file tests/demo/foo.h
patching file tests/depdemo/sysdep.h
patching file tests/depdemo/l1/l1.h
patching file tests/depdemo/l2/l2.h
patching file tests/depdemo/l3/l3.h
patching file tests/depdemo/l4/l4.h
patching file tests/pdemo/foo.h

Re: PGI Compiler patch for cygwin

2006-02-21 Thread Christopher Hulbert

I get this error compiling libtool.  It looks like it's trying to
extract the symbols from libltdl/.libs/libltdl.lax/loadlibrary.lib,
but the symbols look like they have paths associated with it and thus
can't extract them because the path doesn't exist.  I guess this is
because the library is created using pgcc which uses the MS hack for
an archiver (lib).  Any ideas?



/bin/sh ./libtool --tag=CC --mode=link pgcc  -g -no-undefined  -o
libltdl/libltdl.la -rpath /usr/local/lib -no-undefined -version-info
7:0:0 -dlpreopen libltdl/loadlibrary.la 
libltdl/loaders/libltdl_libltdl_la-preopen.lo
libltdl/libltdl_libltdl_la-lt__alloc.lo
libltdl/libltdl_libltdl_la-lt_dlloader.lo
libltdl/libltdl_libltdl_la-lt_error.lo
libltdl/libltdl_libltdl_la-ltdl.lo libltdl/libltdl_libltdl_la-slist.lo
argz.lo lt__strl.lo
libtool: link: rm -f libltdl/.libs/libltdl.nm
libltdl/.libs/libltdl.nmS libltdl/.libs/libltdl.nmT
libtool: link: creating libltdl/.libs/libltdlS.c
libtool: link: extracting global C symbols from `libltdl/.libs/loadlibrary.lib'
libtool: link: (cd libltdl/.libs  pgcc -g -c  libltdlS.c)
libtool: link: rm -f libltdl/.libs/libltdlS.c
libltdl/.libs/libltdl.nm libltdl/.libs/libltdl.nmS
libltdl/.libs/libltdl.nmT
libtool: link: (cd libltdl/.libs/libltdl.lax/loadlibrary.lib  ar x
/cygdrive/c/cygwin/home/chulbert/libtool-build/libltdl/.libs/loadlibrary.lib)
libltdl/loaders/.libs/loadlibrary.o: No such file or directory
make[2]: *** [libltdl/libltdl.la] Error 1
make[2]: Leaving directory `/cygdrive/c/cygwin/home/chulbert/libtool-build'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/cygdrive/c/cygwin/home/chulbert/libtool-build'
make: *** [all] Error 2


bash-3.00$ lib -list libltdl/.libs/loadlibrary.lib
Microsoft (R) Library Manager Version 7.10.3077
Copyright (C) Microsoft Corporation.  All rights reserved.

libltdl/loaders/.libs/loadlibrary.o

bash-3.00$ ar t libltdl/.libs/loadlibrary.lib
libltdl/loaders/.libs/loadlibrary.o




On 2/21/06, Ralf Wildenhues [EMAIL PROTECTED] wrote:
 * Christopher Hulbert wrote on Tue, Feb 21, 2006 at 04:53:31PM CET:
  On 2/21/06, Ralf Wildenhues [EMAIL PROTECTED] wrote:
   * Christopher Hulbert wrote on Tue, Feb 21, 2006 at 03:15:42PM CET:
   
I looked at the failure for fcdemo.  It
looks like autoconf's AC_FC_LIBRARY_LDFLAGS is not picking up the PGI
libraries because they are wrapped in single quotes, i.e.
'-Lc:\Program Files\PGI/nt86/6.0/lib'.
  
   Hmpf.  That'll be difficult to get both fixed in _AC_PROG_FC_V_OUTPUT
   and also all the way through Autoconf and Libtool so the embedded space
   isn't killed (or the path broken in two arguments).
 
  Not sure what's going on here.  I use the AC_FC_LIBRARY_LDFLAGS in my
  configure.ac and I don't get that problem.  libtool's configure must
  be quoting each of these arguments??? I should note that I had to
  patch fortran.m4 (a long time ago) to handle a case where the library
  was butted up against a single quote such as 'blah blah -lm'.  I
  thought I sent that info to the autoconf list a while ago???

 The issue you sent to the Autoconf list was slightly different, and the
 patch I posted to fix it matched very narrowly (to lessen the chance of
 interfering with other compilers' output, or so I must have thought back
 then).

 You should also note that, if you use the nightly tarballs, they are
 bootstrapped with Autoconf 2.59, but aforementioned patch was added to
 Autoconf after 2.59.  Hopefully, Autoconf 2.60 will be out soon.

   Also I think we need to stick `-Mnomain' in Fortran archive_cmds
   otherwise fcdemo will fail again.
 
  Well, that depends on how you link.  I link my C code against the
  archived fortran code separately so without forcing automake to use
  LD=$(FC), it uses the C compiler, so I don't need -Mnomain (hence the
  use of AC_FC_LIBRARY_LDFLAGS).

 Oh.  Ok.  But I think libtool has always tried not to emit a dependency
 to the Fortran main function into the shared libraries it creates.  I
 believe it would only be consistent if we continued to do this now.
 Does it break anything?

I don't think it would break anything, but I don't think the fortran
compiler puts in a main when creating shared libraries.  Are you
trying to avoid the DllMain routine?  If so you want -Mnopgdllmain. 
The doc says that the latest version of the PGI DllMain are included
in the release notes and must be included for proper functioning of
the dll. I would think under windows unless the user gives a specific
entry point or tells libtool not to use the DllMain, you may want to
leave that. Just my opinion though.


 Cheers,
 Ralf

Re: PGI Compiler patch for cygwin

2006-02-21 Thread Ralf Wildenhues

* Christopher Hulbert wrote on Tue, Feb 21, 2006 at 04:53:31PM CET:
 On 2/21/06, Ralf Wildenhues [EMAIL PROTECTED] wrote:
  * Christopher Hulbert wrote on Tue, Feb 21, 2006 at 03:15:42PM CET:
  
   I looked at the failure for fcdemo.  It
   looks like autoconf's AC_FC_LIBRARY_LDFLAGS is not picking up the PGI
   libraries because they are wrapped in single quotes, i.e.
   '-Lc:\Program Files\PGI/nt86/6.0/lib'.
 
  Hmpf.  That'll be difficult to get both fixed in _AC_PROG_FC_V_OUTPUT
  and also all the way through Autoconf and Libtool so the embedded space
  isn't killed (or the path broken in two arguments).
 
 Not sure what's going on here.  I use the AC_FC_LIBRARY_LDFLAGS in my
 configure.ac and I don't get that problem.  libtool's configure must
 be quoting each of these arguments??? I should note that I had to
 patch fortran.m4 (a long time ago) to handle a case where the library
 was butted up against a single quote such as 'blah blah -lm'.  I
 thought I sent that info to the autoconf list a while ago???

The issue you sent to the Autoconf list was slightly different, and the
patch I posted to fix it matched very narrowly (to lessen the chance of
interfering with other compilers' output, or so I must have thought back
then).

You should also note that, if you use the nightly tarballs, they are
bootstrapped with Autoconf 2.59, but aforementioned patch was added to
Autoconf after 2.59.  Hopefully, Autoconf 2.60 will be out soon.

  Also I think we need to stick `-Mnomain' in Fortran archive_cmds
  otherwise fcdemo will fail again.
 
 Well, that depends on how you link.  I link my C code against the
 archived fortran code separately so without forcing automake to use
 LD=$(FC), it uses the C compiler, so I don't need -Mnomain (hence the
 use of AC_FC_LIBRARY_LDFLAGS).

Oh.  Ok.  But I think libtool has always tried not to emit a dependency
to the Fortran main function into the shared libraries it creates.  I
believe it would only be consistent if we continued to do this now.
Does it break anything?

Cheers,
Ralf

Re: HEAD: static tests

2006-02-21 Thread Gary V. Vaughan

Hallo Ralf,

In principle, this seems like a good thing to go in, except that I still
have one nagging doubt:  If 1.5.22 is the only release with the
regressed semantics for -static, then for bugwards compatibility, I'd be
inclined to revert to it's former meaning with years old pedigree, and
come up with a new flag name for the (better) semantics we introduced in
1.5.22...

Hmmm (thinking out loud), might it be better to come up with two
entirely new flag names, one for non-1.5.22 semantics and another for
1.5.22 semantics to recommend from here on in.  If we get a '-static'
flag, we should then issue a big fat warning that for compatibility
we will interpret this flag as for pre-1.5.22, but it would be better
for the developer to pass one of the new flag names instead to avoid
ambiguity in the future.

What say you?

Cheers,
Gary.

Ralf Wildenhues wrote:
* Ralf Wildenhues wrote on Mon, Jan 30, 2006 at 02:01:53PM CET:

I will followup to this mail (to libtool-patches only for size) with a
patch to implement per-deplib flags for programs (for CVS HEAD) and add
comprehensive tests for the static flags.

Here goes the test.  Note that the tests uncovered that hardcoding
was not done in all cases where necessary with the `-static' flag
since we changed its behavior; a fix will be proposed in a followup.
 
 
 Small update to the proposed patch: if link_static_flag is empty, don't
 expect `-all-static' to do wonders magically.  Add keyword, remove some
 cruft leftover from testing.
 
 I intend to apply as one patch.  If ok..
 
 Cheers,
 Ralf
 
 
  * tests/static.at: New tests for comprehensive test exposure of
  all current and proposed static linking flags for programs.
  * Makefile.am, tests/testsuite.at: Updated.
 
 
 
 --- tests/static.at   2006-02-21 08:29:17.0 +0100
 +++ tests/static.at   2006-02-03 10:14:52.0 +0100
 @@ -63,6 +63,7 @@
  #   (most likely the Sun compiler suite will be the only problem child).
  
  AT_SETUP([static linking flags for programs])
 +AT_KEYWORDS([libtool])
  
  LDFLAGS=$LDFLAGS -no-undefined
  prefix=`pwd`/inst
 @@ -207,7 +227,7 @@
# global static flags.
for st in -static -static-libtool-libs -all-static; do
  AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS $st -o m$st 
 m.$OBJEXT \
 -   -L${libdir}1 $R -la1 a2/liba2.la -L${libdir}3 -R${libdir}3 -la3],
 +   -L${libdir}1 -la1 a2/liba2.la -L${libdir}3 -R${libdir}3 -la3],
[0], [ignore], [ignore])
done
  
 @@ -270,21 +292,26 @@
# - remove the library images to catch failure to link 
 statically/dynamically,
# - add false other deplibs in the paths to catch (some) wrongly added run 
 paths.
  
 +  # if -all-static does not work, do not exercise it any more.
 +  all_static=-all-static
 +  eval `$LIBTOOL --config | grep '^link_static_flag='`
 +  test -z $link_static_flag  all_static=
 +
echo ### test whether installed libtool library liba2 was linked 
 statically
func_move_libs a2 ${libdir}2
 -  func_test_exec -static -static-libtool-libs -all-static `$per_deplib  
 echo 2 12 23 123 123a`
 +  func_test_exec -static -static-libtool-libs $all_static `$per_deplib  
 echo 2 12 23 123 123a`
$per_deplib  func_test_exec_fail 1 3 13 31
func_restore_libs a2 ${libdir}2
  
echo ### test whether uninstalled libtool library liba1 was linked 
 statically
func_move_libs a1 ${libdir}1
 -  func_test_exec -static-libtool-libs -all-static `$per_deplib  echo 1 12 
 13 31 123 123a`
 +  func_test_exec -static-libtool-libs $all_static `$per_deplib  echo 1 12 
 13 31 123 123a`
$per_deplib  func_test_exec_fail -static 2 3 23
func_restore_libs a1 ${libdir}1
  
echo ### test whether non-libtool library liba3 was linked statically
func_move_libs a3 ${libdir}3
 -  func_test_exec -all-static `$per_deplib  echo 3 13 23 31 123 123a`
 +  func_test_exec $all_static `$per_deplib  echo 3 13 23 31 123 123a`
func_test_exec_fail -static -static-libtool-libs `$per_deplib  echo 1 2 
 12`
func_restore_libs a3 ${libdir}3
  
 
 

-- 
Gary V. Vaughan  ())_.  [EMAIL PROTECTED],gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker   / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook


signature.asc
Description: OpenPGP digital signature

Re: PGI Compiler patch for cygwin

2006-02-21 Thread Christopher Hulbert

On 2/21/06, Ralf Wildenhues [EMAIL PROTECTED] wrote:
 * Christopher Hulbert wrote on Tue, Feb 21, 2006 at 07:18:17PM CET:
  On 2/21/06, Ralf Wildenhues [EMAIL PROTECTED] wrote:

   http://article.gmane.org/gmane.comp.sysutils.automake.general/6539

  It seems the patch is no longer available.  The link refers to
  6539-001.bin which doesn't exist.  Doing a directory listing lists
  only 6539 and nothing else related to the thread.

 :-(  I did not know gmane expires attachments or hides them.
 This is the same article:
 http://lists.gnu.org/archive/html/libtool-patches/2005-11/msg00190.html

 Cheers,
 Ralf


I can't seem to shake this error.  Attahed is the config.log and make
output in a bzipped tar file.

Chris


pgi_patch_error.tar.bz2
Description: BZip2 compressed data

Re: HEAD: static tests

some pending patches (was: document some more libtool variables)

Re: PGI Compiler patch for cygwin

Re: PGI Compiler patch for cygwin

Re: fix the locking issue

Re: PGI Compiler patch for cygwin

Re: PGI Compiler patch for cygwin

Re: PGI Compiler patch for cygwin

Re: HEAD: static tests

Re: PGI Compiler patch for cygwin

10 matches

Site Navigation

Mail list logo

Footer information