Re: [PATCH 1/4] Support GCC LTO on GNU/Linux.

2010-04-05 Thread Dave Korn
On 04/04/2010 18:53, Charles Wilson wrote:

 One thing I worry about -- but can't test on my platform, since cygwin's
 compiler is not up to the latest-and-greatest yet so doesn't yet support
 LTO -- is whether this bit, in the cwrapper, will break:
 
 const char * MAGIC_EXE = $magic_exe;

 It's been my understanding that sticking random static variables into an
 application, when that variable is never accessed by the app's code, is
 one of the things that gets optimized out by LTO.
 
 Can anybody confirm that this sort of thing will continue to work, even
 with LTO turned on?

  There's surely no need to build the wrapper with LTO just because the target
application is built that way?

  As for whether it would get dropped if you did, I'd imagine that's quite
plausible; you might want to add a volatile qualifier.

cheers,
  DaveK





Re: [PATCH 2/4] Fix incompatible struct declarations.

2010-04-05 Thread Bob Friesenhahn

On Sun, 4 Apr 2010, Ralf Wildenhues wrote:


Wow, that's a plain incompatibility with (C) in any C dialect!

Thus far the analysis.  Question is, how do we fix it.  My preference
would be to fix the manual and the test cases, since the actual code has
been fairly stable.


That is a reasonable approach.


Then it only remains to fix the const-ness in the declaration.  In a
followup.

OK to apply?


Yes, please do.

Bob



Thanks,
Ralf

ChangeLog |9 +
doc/libtool.texi  |   26 ++
tests/demo/dlmain.c   |   11 ++-
tests/pdemo/longer_file_name_dlmain.c |   11 ++-
4 files changed, 31 insertions(+), 26 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index b324240..c082cee 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,14 @@
2010-04-04  Ralf Wildenhues  ralf.wildenh...@gmx.de

+   Fix incompatible struct declarations.
+   * doc/libtool.texi (Dlpreopening): Remove broken documentation
+   of lt_dlsymbol and lt_dlsymlist.  Document typedef lt_dlsymlist
+   and symbol lt_preloaded_symbols according to the implementation.
+   * tests/demo/dlmain.c (lt_symlist): Make struct anonymous ...
+   (lt_dlsymlist): ... and typedef to this name.
+   (lt_preloaded_symbols, main): Adjust.
+   * tests/pdemo/longer_file_name_dlmain.c: Likewise.
+
Support GCC LTO on GNU/Linux.
* NEWS: Update.
* libltdl/config/ltmain.m4sh (func_mode_link): Allow through
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 323bf4e..f73f5a7 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -3388,25 +3388,15 @@ you must declare the objects you want your application 
to dlopen by
using the @option{-dlopen} or @option{-dlpreopen} flags when you link your
program (@pxref{Link mode}).

-...@deftypefn {Structure} {struct} lt_dlsymbol @{ @w{const char 
*...@var{name};} @w{void *...@var{address};} @}
+...@deftp {Data Type} {lt_dlsymlist} typedef struct @
+  @{ @w{const char *...@var{name};} @w{void *...@var{address};} @} lt_dlsymlist
The @var{name} attribute is a null-terminated character string of the
symbol name, such as @code{fprintf}.  The @var{address} attribute is a
generic pointer to the appropriate object, such as @code{fprintf}.
-...@end deftypefn
-
-...@deftypefn {Structure} {struct} lt_dlsymlist @{ @w{const char 
*...@var{originator};} @w{const lt_dlsymbol @var{symbols}[];} @}
-The @var{originator} attribute is a null-terminated character string,
-naming the compilation unit that @var{symbols} were preloaded on
-behalf of.  This is usually the basename of a library,
-...@file{libltdl.la} has a corresponding @var{originator} value of
-...@samp{libltdl}; if the @var{symbols} are for the benefit of the
-application proper, then @var{originator} is @samp{@@PROGRAM@@},
-though Libtool takes care of that detail if you use
-...@samp{ltdl_set_preloaded_symbols}.
-...@end deftypefn
+...@end deftp

-...@deftypevar {const lt_dlsymlist *} lt_preloaded_symbols
-An array of @var{lt_symbol} structures, representing all the preloaded
+...@deftypevar {const lt_dlsymlist } lt_preloaded_symbols[]
+An array of @var{lt_dlsymlist} structures, representing all the preloaded
symbols linked into the program proper.  For each module
@option{-dlpreopen}ed by the Libtool linked program
there is an element with the @var{name} of the module and an @var{address}
@@ -3414,6 +3404,10 @@ of @code{0}, followed by all symbols exported from this 
file.
For the executable itself the special name @samp{@@PROGRAM@@} is used.
The last element of all has a @var{name} and @var{address} of
@code{0}.
+
+To facilitate inclusion of symbol lists into libraries,
+...@code{lt_preloaded_symbols} is @samp{#define}d to a suitably unique name
+in @file{ltdl.h}.
@end deftypevar

Some compilers may allow identifiers that are not valid in ANSI C, such
diff --git a/tests/demo/dlmain.c b/tests/demo/dlmain.c
index 0d42d88..c970998 100644
--- a/tests/demo/dlmain.c
+++ b/tests/demo/dlmain.c
@@ -1,6 +1,7 @@
/* dlmain.c -- hello test program that uses simulated dynamic linking

-   Copyright (C) 1996-1999, 2004, 2006, 2007 Free Software Foundation, Inc.
+   Copyright (C) 1996-1999, 2004, 2006, 2007, 2010 Free Software
+   Foundation, Inc.

   This file is part of GNU Libtool.

@@ -27,18 +28,18 @@ or obtained by writing to the Free Software Foundation, 
Inc.,

#define lt_preloaded_symbols lt__PROGRAM__LTX_preloaded_symbols

-struct lt_symlist
+typedef struct
{
  const char *name;
  lt_ptr_t address;
-};
+} lt_dlsymlist;

-extern const struct lt_symlist lt_preloaded_symbols[];
+extern const lt_dlsymlist lt_preloaded_symbols[];

int
main ()
{
-  const struct lt_symlist *s;
+  const lt_dlsymlist *s;
  int (*pfoo)() = 0;
  int (*phello)() = 0;
  int *pnothing = 0;
diff --git a/tests/pdemo/longer_file_name_dlmain.c 
b/tests/pdemo/longer_file_name_dlmain.c
index fdb5526..ef1e4c5 100644
--- a/tests/pdemo/longer_file_name_dlmain.c
+++ 

Re: [PATCH 1/4] Support GCC LTO on GNU/Linux.

2010-04-05 Thread Charles Wilson
On 4/5/2010 10:53 AM, Dave Korn wrote:
 On 04/04/2010 18:53, Charles Wilson wrote:
 Can anybody confirm that this sort of thing will continue to work, even
 with LTO turned on?
 
   There's surely no need to build the wrapper with LTO just because the target
 application is built that way?

No, but the wrapper is built using the target compiler, with all of the
target flags.  We've talked about maybe filtering that command (e.g.
strip -Werror -- or -WX for cl.exe -- just so that slight problems
in the cwrapper don't bring someone's build to a crashing halt).  But so
far, nothing along those lines has happened.

   As for whether it would get dropped if you did, I'd imagine that's quite
 plausible; you might want to add a volatile qualifier.

'static volatile const char * MAGIC = ...'
^^
err...maybe just 'volatile'!

--
Chuck