index b9abe8a..6b76340 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2010-09-12 Charles Wilson ...
+
+ When assigning $linklib value, honor [-all]-static[-libtool-libs]
+
+ * libltdl/config/ltmain.m4sh (func_mode_link): When prefer_static_libs
+ and static library
On 9/14/2010 2:04 AM, Gary V. Vaughan wrote:
I'm curious to know what the history of lzma and xz is that makes this
desirable though.
Here's some documentation I put together for the cygwin xz package:
xz
This package
On 9/14/2010 11:02 AM, Bob Friesenhahn wrote:
On Tue, 14 Sep 2010, Gary V. Vaughan wrote:
No objections.
I'm curious to know what the history of lzma and xz is that makes this
desirable though.
I am curious to know if XZ Utils has now achieved a proper stable
release or if it will be
On 9/16/2010 1:28 PM, Ralf Wildenhues wrote:
do I see it right that there are no pending w32 patches for before
the next Libtool release any more (after the one I just acked)?
My most recent cygwin-special libtool release has the following four
patches:
On 9/16/2010 2:55 PM, Ralf Wildenhues wrote:
This looks ok, but wouldn't the shell wrapper need this as well,
seeing that it could be run on w32 too (IIRC)?
You're right. I had looked at this before, and erroneously concluded
that the shell wrapper was DTRT. But...it isn't. Also, my
On 9/16/2010 3:52 PM, Vincent Torri wrote:
do I see it right that there are no pending w32 patches for before
the next Libtool release any more (after the one I just acked)?
there is a mingw-w64 issue i have mentioned 2 times, with a debug log of
libtool.
This is the Warning: linker path
* libltdl/config/ltmain.m4sh (func_mode_link): Avoid poor syntax.
---
Without this, sh.test fails. Committed as obvious (no, really, this time).
--
Chuck
libltdl/config/ltmain.m4sh |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libltdl/config/ltmain.m4sh
* libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src:main): Call
lt_update_exe_path before lt_update_lib_path, to ensure that the
temporary rpath values (which include the OBJDIRs of uninstalled
libtool libraries) precede installation and final -rpath directories.
(func_emit_wrapper): Prepend
On 9/17/2010 12:53 PM, Ralf Wildenhues wrote:
let the review sprint begin ...
Meh -- no more patches from me in the near term. I promised two small
patches yesterday, delivered today. Whether they are reviewed and
pushed before the release or not doesn't matter that much.
--
Chuck
On 9/17/2010 1:23 PM, Ralf Wildenhues wrote:
And since IIRC
Gary wanted to do the release this weekend, I wonder whether this isn't
more safely pushed to after the relase. WDYT?
FWIW, I agree that this patch should be postponed until after the
release. I'm agnostic on whether tests -- such
On 9/17/2010 1:30 PM, Ralf Wildenhues wrote:
* Charles Wilson wrote on Fri, Sep 17, 2010 at 06:28:46PM CEST:
OK to push?
OK. Why the s/system/platform/ changes though? I see that
libtool.texi uses platform a lot, and also uses system quite a bit but
not quite as often. Other GNU
On 9/17/2010 1:30 PM, Ralf Wildenhues wrote:
* Charles Wilson wrote on Fri, Sep 17, 2010 at 06:28:46PM CEST:
OK to push?
OK.
Pushed.
--
Chuck
On 9/17/2010 2:12 PM, Ralf Wildenhues wrote:
* Charles Wilson wrote on Fri, Sep 17, 2010 at 06:23:28PM CEST:
* libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src:main): Call
lt_update_exe_path before lt_update_lib_path, to ensure that the
temporary rpath values (which include the OBJDIRs
On 9/21/2010 1:33 PM, Ralf Wildenhues wrote:
Hi Peter,
* Peter Rosin wrote on Tue, Sep 21, 2010 at 09:37:16AM CEST:
I know it's late for the release, but I'd like to squeeze this one in
too, if at all possible. After all, it doesn't affect anything but MSVC.
I have questions:
What does
On 9/23/2010 6:25 PM, Peter Rosin wrote:
I don't know how to set up the defines so that EXTERN becomes
1. extern when you use a static library
2. extern when you build a static library
3. extern declspec(dllimport) when you use a shared library
4. extern declspec(dllexport) when you build a
On 9/24/2010 8:44 AM, Peter Rosin wrote:
Yes indeed, I intended __declspec. I have revised the patch so that it
handles building correctly (dllexport for dlls, not for static) and
using the best way possible (still dllimports from from both dlls and
static libs).
Well, I'm confused. The
On 9/24/2010 8:13 PM, Roumen Petrov wrote:
About pre-processor flags - better is C code to start with #define
BUIILD_FOO instead -DBUIILD_FOO in makefile.
No, actually, it is not better. The reason is, any given C file *might*
be used in a library, or it *might* be used in an application -- or
On 9/24/2010 8:06 PM, Roumen Petrov wrote:
I would like to propose different macros for export/import of variables
in format:
#define XXX(type)decorator_before type decorator_after
Why? Peter's formula is practically universal in most packages I have
seen (ncurses is the only
On 9/24/2010 2:53 PM, Ralf Wildenhues wrote:
Den 2010-09-24 19:30 skrev Charles Wilson:
That is the typical approach. The drawback -- usually an acceptable one
-- is that if you are building a stack of dependent DLLs:
EXE -- C.DLL - B.DLL
-- A.DLL
Then (a) you must link exe using
On 9/24/2010 2:46 PM, Peter Rosin wrote:
Now I'm also confused.
That's not good.
/me double checks (see below)
WHAT? It doesn't work as I stated!?!
*ponders that for a bit*
*scratches head*
Ahh, you said libtool does this by default IIRC. If that's actually the
case than that is
On 9/29/2010 4:06 AM, Peter Rosin wrote:
Cygwin is always running with this error mode (I think), MSYS is not.
Cygwin no longer supports Win9x, MSYS does.
Will this patch cause any issues if people try to use libtool + MSYS on
a Win9x system?
--
Chuck
On 9/29/2010 10:15 AM, Peter Rosin wrote:
Den 2010-09-29 15:47 skrev Charles Wilson:
Will this patch cause any issues if people try to use libtool + MSYS on
a Win9x system?
I don't foresee any problems, because SetErrorMode is really old. You
were worrying about the entry point not being
On 10/4/2010 1:14 AM, Ralf Wildenhues wrote:
OK with nits addressed. You may want to use a ChangeLog and/or --author
entry that suitably documents the main author of the patch.
Updated and pushed as attached.
--
Chuck
diff --git a/ChangeLog b/ChangeLog
index c0492fe..9caba84 100644
---
On 10/20/2010 2:31 AM, Peter Rosin wrote:
Den 2010-10-05 13:33 skrev Peter Rosin:
I have implemented exactly that and just posted this to the MinGW patch
tracker:
http://sourceforge.net/tracker/index.php?func=detailaid=3081421group_id=2435atid=302435
The silence is deafening.
Chuck,
On 11/10/2010 1:29 PM, Ralf Wildenhues wrote:
-AT_CHECK([$LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c m.c],
- [], [ignore], [ignore])
+AT_CHECK([$CC $CPPFLAGS $CFLAGS -c m.c], [], [ignore], [ignore])
AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o m1$EXEEXT
On 11/10/2010 4:07 PM, Ralf Wildenhues wrote:
* Charles Wilson wrote on Wed, Nov 10, 2010 at 09:46:54PM CET:
Wouldn't a better fix be to change the link command to reference m.lo
instead of m.$OBJEXT ?
That would be an alternative, but it would mean that we (needlessly) use
PIC code
On 1/7/2011 3:02 AM, Peter Rosin wrote:
Den 2011-01-06 21:29 skrev Ralf Wildenhues:
* Peter Rosin wrote on Tue, Jan 04, 2011 at 05:44:58PM CET:
Before I tie up the lose ends with this patch, I wonder if Ralf (or someone
else) could tell me if I should also fix the other assignments of
On 1/7/2011 1:18 PM, Ralf Wildenhues wrote:
Err...that's not really uncommon.
[...]
OK, but I still would accept those kinds of changes to code for
little-used system only when someone has actually *tested* them in that
particular situation, and found the code to be erroneous prior patch
On 1/16/2011 12:13 PM, Ralf Wildenhues wrote:
(I for one often do 'make install DESTDIR=/tmp/dest' merely to
tar up the installation tree to be scp'ed to another machine where
the NFS share is mounted rw.)
Actually, Ralf's example (or one very similar to it) is the *primary*
use of DESTDIR.
On 1/17/2011 8:23 AM, Martin Panter wrote:
On 16 January 2011 17:23, Charles Wilson wrote:
Actually, Ralf's example (or one very similar to it) is the *primary*
use of DESTDIR. It's how many packaging tools -- like rpm, or cygport
on cygwin -- create installable binary packages.
Agreed
On 6/23/2011 5:34 AM, Vadim Zeitlin wrote:
Re-declaring _putenv() without _CRTIMP in strict ANSI mode when using MinGW
resulted in a warning because of a conflict with the previous declaration that
did use _CRTIMP.
Simply add _CRTIMP to our declaration to avoid it.
-int _putenv (const char
On 11/5/2011 12:40 PM, Gary V. Vaughan wrote:
By the end of this particular set, libtoolize will have moved from the kludgy
sed based interrogation of configure.ac to probe the arguments to various
important macros so that it can determine what files to copy and where... to
the much more
On 11/15/2011 7:53 AM, Gary V. Vaughan wrote:
* cfg.mk (local-checks-to-fix): Remove
sc_cast_of_x_alloc_return_value from list of disabled checks.
* libltdl/config/ltmain.m4sh (XMALLOC, XFREE): Unroll into their
xmalloc and free expansions so that this syntax-check can find
violations, and
On 11/15/2011 11:36 AM, Charles Wilson wrote:
On 11/15/2011 7:53 AM, Gary V. Vaughan wrote:
* cfg.mk (local-checks-to-fix): Remove
sc_cast_of_x_alloc_return_value from list of disabled checks.
* libltdl/config/ltmain.m4sh (XMALLOC, XFREE): Unroll into their
xmalloc and free expansions so
On 11/15/2011 7:53 AM, Gary V. Vaughan wrote:
tests/mdemo/Makefile.am
-## use @LIBLTDL@ because some broken makes do not accept macros in targets
+## use $(LIBLTDL) because some broken makes do not accept macros in targets
This comment now makes zero sense. If you are now forcing the following
On 11/25/2011 11:57 PM, Gary V. Vaughan wrote:
On 26 Nov 2011, at 11:39, Charles Wilson wrote:
a) This is a big holiday weekend in the US, so...a bit more than 72
hours is indicated. Most of us will still be catching up on
post-holiday $realjob stuff by the time 72 hours expires.
Ah
On 11/28/2011 12:12 PM, Charles Wilson wrote:
Attached, see test log for $host=cygwin. I had to use 'make -k check
gl_public_submodule_commit=' -- I'm not sure why, but perhaps your
working tree is using private gnulib mods?
I'll send testsuite.dir privately.
I've attached the test log
On 12/8/2011 5:21 AM, Gary V. Vaughan wrote:
The recently pushed series of patches included the controversial
introduction of an additional 3 forks per invocation, which might
add a minute or two of wall-clock time to giant builds on windows.
By assuming that windows will run shell scripts on
On 12/8/2011 11:22 AM, Eric Blake wrote:
On 12/08/2011 08:29 AM, Charles Wilson wrote:
cygwin + libtool + dash/posh (e.g. small, fast shell -- without XSI)
Umm, dash has XSI features (where XSI features covers things like
${var##prefix}). ... Meanwhile, libtool is using more than just XSI
On 10/5/2012 12:03 PM, Gary V. Vaughan wrote:
And thanks for looking into it. Is there a legal way to get access
to Windows and the various flavours of gcc and MSVC that libtool users
care about, without spending hundreds of dollars on software I would
never use for anything else?
Yes.
MS
On 10/5/2012 2:28 PM, Bob Friesenhahn wrote:
I
wouldn't recommend that anyone start with XP these days since it is 12
years old, patched beyond all repair, and quickly becoming defunct.
Seconded. A virtual machine with stock XP will need several full days
of running Windows Update to bring it
On 11/8/2013 1:49 PM, Bob Friesenhahn wrote:
Isn't it because libtool wants to control the order of the linking and
assure that all dependencies (including static) are tracked/known and
applied at the correct times? It wants to assure that static
dependencies are linked into the dependent
501 - 542 of 542 matches
Mail list logo
