On 7/4/2010 2:29 PM, Ralf Wildenhues wrote:
* Charles Wilson wrote on Sun, Jul 04, 2010 at 06:15:06AM CEST:
So...this is what I intend to push, barring objections.
No objections from me, please wait however long I asked you to wait
(basically long enough so others have had a chance to chime
Hi Chuck,
On 3 Jul 2010, at 22:34, Charles Wilson wrote:
It's non-timely and off-point reviews that I tire of.
The non-timely bit is just a reflection of the manpower and free time
issues that all open source projects are subject to, so that kinda goes
with the territory. Nobody likes it,
On Sat, 3 Jul 2010, Charles Wilson wrote:
No one is threatening your committer status.
I didn't say they were. But if I *did* misbehave -- well, I could
hardly be surprised by the inevitable consequences, could I? Doesn't
take a genius to predict those consequences, either.
Misbehavior is
* Charles Wilson wrote on Sun, Jul 04, 2010 at 06:15:06AM CEST:
On 6/26/2010 2:51 PM, Ralf Wildenhues wrote:
OK. Here's my take on this: if you fix all nits I noted inline below,
post the updated and tested patch (you decide what testing is needed),
then you are OK to commit after 72 hours
Hi Charles,
* Charles Wilson wrote on Sat, Jul 03, 2010 at 06:10:57PM CEST:
On 6/28/2010 2:10 AM, Ralf Wildenhues wrote:
* Charles Wilson wrote on Mon, Jun 28, 2010 at 12:05:40AM CEST:
It obviously isn't SUPPOSED to be dead -- or it wouldn't be there.
Well, I wouldn't put my money on
On 6/28/2010 3:23 AM, Gary V. Vaughan wrote:
Hi Chuck,
Thanks for persevering with the Windows support in Libtool.
Regarding our patch review process, I honestly find the tough reviews
valuable in keeping up the quality of my patches, not least because it
makes me more careful not to
On 6/28/2010 2:10 AM, Ralf Wildenhues wrote:
* Charles Wilson wrote on Mon, Jun 28, 2010 at 12:05:40AM CEST:
So...we APPEAR to have a bunch of dead code.
I wasn't aware of that. Sorry about the sloppy review.
It obviously isn't
SUPPOSED to be dead -- or it wouldn't be there.
Well, I
On Sat, 3 Jul 2010, Charles Wilson wrote:
That's an...interesting take. I've never assumed that ANY contribution
would be acceptable unless it received an actual approval by a
maintainer. I mean, really: here's this patch, and no single maintainer
has endorsed it without some significant
On 7/3/2010 7:05 PM, Bob Friesenhahn wrote:
On Sat, 3 Jul 2010, Charles Wilson wrote:
That's an...interesting take. I've never assumed that ANY contribution
I think that you are attributing to much special status to official
maintainers. It should not matter where approval comes from as
On 6/26/2010 2:51 PM, Ralf Wildenhues wrote:
OK. Here's my take on this: if you fix all nits I noted inline below,
post the updated and tested patch (you decide what testing is needed),
then you are OK to commit after 72 hours of waiting. FWIW, I'm likely
not available most of next week; if
Hello Charles,
* Charles Wilson wrote on Mon, Jun 28, 2010 at 12:05:40AM CEST:
On 6/27/2010 4:43 PM, Ralf Wildenhues wrote:
* Charles Wilson wrote on Sun, Jun 27, 2010 at 02:51:21PM CEST:
So...can I get a verdict? Is -dlpreopen not-an-la-file supposed to work?
I think Pierre's report
Hi Chuck,
Thanks for persevering with the Windows support in Libtool.
Regarding our patch review process, I honestly find the tough reviews
valuable in keeping up the quality of my patches, not least because it
makes me more careful not to leave loose ends in my submissions.
Nevertheless,
On 6/26/2010 2:51 PM, Ralf Wildenhues wrote:
* Charles Wilson wrote on Fri, Jun 25, 2010 at 04:57:15AM CEST:
However, with this patch, helldl.exeS.c has:
IOW, all the spurious declarations are gone? That'd be cool.
Correct.
(*) Note that you only need to determine the dll name for an
* Charles Wilson wrote on Sun, Jun 27, 2010 at 02:51:21PM CEST:
In that case, Ralf's suggested libfile_$(transliterated implib name)
is used, because we have the .la file available which allows that
shortcut. The only time we need `dlltool --identify' is when
dlpreopening a non-libtool
On Sun, 27 Jun 2010, Ralf Wildenhues wrote:
* Charles Wilson wrote on Sun, Jun 27, 2010 at 02:51:21PM CEST:
In that case, Ralf's suggested libfile_$(transliterated implib name)
is used, because we have the .la file available which allows that
shortcut. The only time we need `dlltool
Hi Charles,
* Charles Wilson wrote on Fri, Jun 25, 2010 at 04:57:15AM CEST:
[...]
Without this patch, when --disable-static on PE/COFF platforms,
dlpreopen symbols are extracted incorrectly (because libtool uses
the same algorithm for extracting symbols from import libs as
from static libs;
* libltdl/config/general.m4sh (func_tr_sh): New function.
* libltdl/config/ltmain.m4sh (func_generate_dlsyms) [cygwin|mingw]:
Obtain DLL name corresponding to import library by using value
stored in unique variable libfile_$(transliterated implib name).
If that fails, use
Charles Wilson wrote:
* libltdl/config/general.m4sh: Update copyright year.
(func_tr_sh): New function.
* libltdl/config/ltmain.m4sh (func_generate_dlsyms) [cygwin|mingw]:
Obtain DLL name corresponding to import library by using value
stored in unique variable libfile_$(transliterated implib
* libltdl/config/general.m4sh: Update copyright year.
(func_tr_sh): New function.
* libltdl/config/ltmain.m4sh (func_generate_dlsyms) [cygwin|mingw]:
Obtain DLL name corresponding to import library by using value
stored in unique variable libfile_$(transliterated implib name).
If that fails, use
Charles Wilson wrote:
The attached, re-re-re-re-revised patch addresses these two issues, but
is otherwise the same as take 4.
Ping.
Most recent version is the take 5 attachment, in this message from two
weeks ago:
http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00232.html
* libltdl/config/general.m4sh: Update copyright year.
(func_tr_sh): New function.
* libltdl/config/ltmain.m4sh (func_generate_dlsyms) [cygwin|mingw]:
Obtain DLL name corresponding to import library by using value
stored in unique variable libfile_$(transliterated implib name).
If that fails, use
Charles Wilson wrote:
Test suite on cygwin/native in progress. Assumming test suite passes, OK?
Comments, Review, Discussion?
All tests pass (cygwin/native):
Old suite:
===
All 113 tests passed
(11 tests were not run)
===
New suite:
76 tests behaved as
Charles Wilson wrote:
Reviewing my own submission...
(func_cygming_dll_for_implib_core): New function.
This function is actually called
func_cygming_dll_for_implib_fallback_core
Need to correct log history.
(func_cygming_implib_p): New function.
Confusing. There is already a
Ralf Wildenhues wrote:
+# func_tr_sh
+# turn $1 into a string suitable for a shell variable name
+# result is stored in $func_tr_sh_result
+func_tr_sh ()
+{
+ func_tr_sh_result=`echo $1 | $SED -e 's/[^A-Za-z0-9_]/_/g'`
+ # ensure result begins with non-digit
+ case $func_tr_sh_result in
Hi Charles,
* Charles Wilson wrote on Fri, Jan 16, 2009 at 02:51:21PM CET:
The unexpected failure was
36: execute mode FAILED (execute-mode.at:193)
but it is unrelated; it's a problem in cygwin-1.7's dos-style path
detection...That's not a path!
--- /dev/null 2006-11-30
Hello Charles,
I haven't looked at your patches in detail yet, but a couple of things
caught my eye:
* Charles Wilson wrote on Sat, Jan 03, 2009 at 02:39:15AM CET:
diff --git a/libltdl/config/general.m4sh b/libltdl/config/general.m4sh
index 4bc304c..c4de91a 100644
---
Charles Wilson wrote:
Full test suite on cygwin in progress. Assuming it passes,
ok for squash and push?
Results: old test suite:
===
All 113 tests passed
(11 tests were not run)
===
New test suite:
ERROR: 76 tests were run,
4 failed (3 expected
Den 2009-01-13 16:41 skrev Charles Wilson:
Peter Rosin wrote:
Den 2009-01-06 02:06 skrev Charles Wilson:
Maybe under that name. But a libbfd-ified version of impgen (as a
replacement for the IMO totally broken -- but part of mingw-utils-0.3 --
reimp program), that happens to also supply an
* libltdl/m4/libtool.m4 (_LT_CHECK_SHAREDLIB_FROM_LINKLIB):
New macro sets sharedlib_from_linklib_cmd variable.
(_LT_DECL_DLLTOOL): New macro ensures DLLTOOL is always set.
* libltdl/config/ltmain.m4sh (func_generate_dlsyms): Use
$sharedlib_from_linklib_cmd instead of directly invoking
Peter Rosin wrote:
Den 2009-01-06 02:06 skrev Charles Wilson:
Maybe under that name. But a libbfd-ified version of impgen (as a
replacement for the IMO totally broken -- but part of mingw-utils-0.3 --
reimp program), that happens to also supply an --identify foo
--identify-ms functionality?
Peter Rosin wrote:
Den 2009-01-05 06:24 skrev Charles Wilson:
Interesting! Meanwhile, I have done some experiments on my own, as I
don't like the dependence on anything that comes with MinGW when
dealing with libtool and MSVC.
I kind of suspected that. What about the attached? This version
Den 2009-01-05 06:24 skrev Charles Wilson:
Charles Wilson wrote:
Charles Wilson wrote:
Peter Rosin wrote:
I'm primarily trying to determine what impact this has on my
MSVC branch...
Ran some experiments on the libraries shipped with the Windows SDK. The
attached script worked ok on most of
Den 2009-01-05 15:08 skrev Charles Wilson:
Peter Rosin wrote:
Den 2009-01-05 06:24 skrev Charles Wilson:
Interesting! Meanwhile, I have done some experiments on my own, as I
don't like the dependence on anything that comes with MinGW when
dealing with libtool and MSVC.
I kind of suspected
Den 2009-01-04 03:35 skrev Charles Wilson:
Peter Rosin wrote:
I'm primarily trying to determine what impact this has on my
MSVC branch...
Den 2009-01-03 02:39 skrev Charles Wilson:
*snip*
+*cygwin* | *mingw* | *cegcc* )
We should strive to have fewer of these in ltmain.m4sh, not
Den 2009-01-06 02:06 skrev Charles Wilson:
Maybe under that name. But a libbfd-ified version of impgen (as a
replacement for the IMO totally broken -- but part of mingw-utils-0.3 --
reimp program), that happens to also supply an --identify foo
--identify-ms functionality? Not so far-fetched.
Charles Wilson wrote:
Peter Rosin wrote:
I'm primarily trying to determine what impact this has on my
MSVC branch...
Ran some experiments on the libraries shipped with the Windows SDK. The
attached script worked ok on most of them. After eliminating the static
libraries and the import
Charles Wilson wrote:
Charles Wilson wrote:
Peter Rosin wrote:
I'm primarily trying to determine what impact this has on my
MSVC branch...
Ran some experiments on the libraries shipped with the Windows SDK. The
attached script worked ok on most of them. After eliminating the static
Hi Chuck,
I'm primarily trying to determine what impact this has on my
MSVC branch...
Den 2009-01-03 02:39 skrev Charles Wilson:
*snip*
+ *cygwin* | *mingw* | *cegcc* )
We should strive to have fewer of these in ltmain.m4sh, not more...
+ func_warn Using fallback code to
Peter Rosin wrote:
I'm primarily trying to determine what impact this has on my
MSVC branch...
Den 2009-01-03 02:39 skrev Charles Wilson:
*snip*
+*cygwin* | *mingw* | *cegcc* )
We should strive to have fewer of these in ltmain.m4sh, not more.
Yep. But the problem is, there are
* libltdl/config/general.m4sh: Adjust copyright date.
(func_tr_sh): New function.
* libltdl/config/ltmain.m4sh: Adjust copyright date.
(func_dlltool_identify): New function.
(func_win32_dllname_for_implib): New function.
(func_generate_dlsyms) [cygwin|mingw]: Obtain DLL name
corresponding to
Charles Wilson wrote:
bootstrapped on cygwin, tested the
demo-{conf|shared|static} + demo-make + demo-exec
test cases with success. Full test suite in progress.
And...4.5 hours later, test suite results on cygwin (1.7.0-37, but that
shouldn't matter. The good news is, cygwin-1.7 now
Hello Brian,
* Brian Dessent wrote on Thu, Nov 13, 2008 at 11:16:24PM CET:
Ralf Wildenhues wrote:
I'm actually not sure whether _GLOBAL__F[ID]_.* can appear on w32.
Do you know? They should happen with C++ code using constructors
and destructors IIRC.
Yes they do occur, although not
Ralf Wildenhues wrote:
Did GCC change since then, or is this system-dependent?
Interesting. I'd be curious to see if powerpc-ibm-aix5.3.0.0-c++filt
recognises the FI/FD encoding, and if so then it would be reasonable to
conclude that this is in fact system-dependent or otherwise an internal
Brian Dessent wrote:
Ralf Wildenhues wrote:
Did GCC change since then, or is this system-dependent?
Interesting. I'd be curious to see if powerpc-ibm-aix5.3.0.0-c++filt
recognises the FI/FD encoding, and if so then it would be reasonable to
conclude that this is in fact system-dependent
Charles Wilson wrote:
Of course, first I need to revise the dlltool patch and get it accepted;
there have been some comments on the binutils list.
Done. Yay!
http://sourceware.org/ml/binutils/2008-11/msg00180.html
Well, that, and it fixes a test that currently fails.
Which one, and can you
Hi Charles,
* Charles Wilson wrote on Thu, Nov 13, 2008 at 06:09:20AM CET:
Ralf Wildenhues wrote:
Well, --verbose is documented to be a reversal of --silent, and
documented to be the default. The fact that opt_verbose is never set is
a limitation. If fixed, that should better happen
Ralf Wildenhues wrote:
I'm actually not sure whether _GLOBAL__F[ID]_.* can appear on w32.
Do you know? They should happen with C++ code using constructors
and destructors IIRC.
Yes they do occur, although not matching that regexp. For one, they
will have two leading underscores before the
On Thu, 13 Nov 2008 22:09:07 +0100, Ralf Wildenhues said:
OK, how about this. It is a slight backward incompatibility, but
not a large one:
- --verbose undoes --silent *and* enables verbose output (that one with
func_verbose),
- --no-silent *only* undoes --silent,
It should still be
* [EMAIL PROTECTED] wrote on Fri, Nov 14, 2008 at 12:28:36AM CET:
The point is, we perhaps STARTED with the .la file, but the whole point
of the dlpreopen $pass is to replace each .la file in $dlprefiles with
the name of the object from which the symbols should be extracted, to
build the
Ralf Wildenhues wrote:
The point is, we perhaps STARTED with the .la file, but the whole point
of the dlpreopen $pass is to replace each .la file in $dlprefiles with
the name of the object from which the symbols should be extracted, to
build the symbol table. So, pick one: either the DLL, or
Ralf Wildenhues wrote:
Hello Charles,
thanks for the patch! Quoting a bit out of order:
* Charles Wilson wrote on Sat, May 31, 2008 at 07:01:45PM CEST:
* libltdl/config/ltmain.m4sh (func_enable_tag): allow
--verbose to set opt_verbose
[...]
A) libtool --verbose does not actually set
* libltdl/config/ltmain.m4sh (func_enable_tag): allow
--verbose to set opt_verbose
(func_win32_dllname_for_implib): New function.
(func_mode_link) [cygwin|mingw]: Use linklib (that is,
import lib) as dlpreopen file, rather than DLL.
(func_generate_dlsyms) [cygwin|mingw]: Use
52 matches
Mail list logo
