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 progra
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
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.
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 us
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 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
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
On 11/25/2011 4:10 AM, Gary V. Vaughan wrote:
As usual, subject to feedback, I'll push this whole series in
72 hours or so. Make distcheck passes for me on my Mac 10.7 and
my Arch Linux x86_64 machines, but it would be great if folks with
a) This is a big holiday weekend in the US, so...a bit
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/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 thei
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, an
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 splendid
On 11/1/2011 10:57 AM, Stefano Lattarini wrote:
> Is `ln -s' portable to e.g., MinGW? Or is the bootstrapping process
> not meant to work there anyway, so we can just not care?
No, bootstrapping is supposed to work (and, until quite recently, did
work) under MinGW/MSYS. Current breakage is rela
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
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 -- cre
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/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 pa
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 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 (
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$EXE
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=detail&aid=3081421&group_id=2435&atid=302435
>
> The silence is deafening.
>
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
--- a/Cha
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 worry
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/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
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
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 exce
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 -- o
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.
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)" whe
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:
>
>
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 valu
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 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
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 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
* doc/libtool.texi (libtool script contents:to_host_file_cmd): Document
variable.
(libtool script contents:to_tool_file_cmd): Prefer `build platform'
to `build system'; Ditto `host platform'.
---
As promised here:
http://lists.gnu.org/archive/html/libtool-patches/2010-09/msg00191.html
OK to push?
* 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 $d
* 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 b/libltdl/con
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
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 changel
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:
0001-cygwin-mingw-Create-UAC-manifest-f
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 i
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 pr
ngeLog
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 st
On 9/12/2010 10:25 AM, Ralf Wildenhues wrote:
> Also, $linklib is used for several other things. It would seem prudent
> to make sure it is clear that this is a very intrusive patch, or use
> another helper variable to make it less intrusive.
Oh, I think linklib was *wrong* no matter what. If yo
On 9/12/2010 10:20 AM, Ralf Wildenhues wrote:
> Hi Charles,
>
> * Charles Wilson wrote on Sun, Sep 12, 2010 at 03:19:51PM CEST:
>> * libltdl/config/ltmain.m4sh (func_mode_link): When prefer_static_libs,
>> ensure old_library name is used as linklib when possible.
>> ---
* libltdl/config/ltmain.m4sh (func_mode_link): When prefer_static_libs,
ensure old_library name is used as linklib when possible.
---
This patch corrects the (long-standing?) failure of mdemo-exec.test on
mingw, but also some non-fatal anomalies in cygwin on the same tests.
Basically, when dlopen'i
On 9/11/2010 4:16 AM, Ralf Wildenhues wrote:
> OK to push.
Pushed.
--
Chuck
On 9/11/2010 2:47 AM, Peter Rosin wrote:
> Den 2010-09-11 07:02 skrev Charles Wilson:
>> OK to push as obvious?
>
> To me, pushing as obvious is the same as pushing without
> asking (and when I do, I make damn sure I don't push anything
> bad). This makes me curious, wha
* libltdl/config/ltmain.m4sh (func_generate_dlsyms): Fix obvious
typo, $sharedlib_from_linklib_cmd missing '_cmd'.
---
Typo in e83da49a1faf9df1c7e351df9e9b175388d76619: there is no variable
named 'sharedlib_from_linklib' -- the variable should be
'sharedlib_from_linklib_cmd'.
OK to push as obvious
On 9/10/2010 10:07 AM, Peter Rosin wrote:
> It's dead, you need the below patch to animate it. There is no sane
> way you can influence the sharedlib_from_linklib variable.
Well, that's just a bug with a known but uncommitted patch. So he's
stopped breathing, but it's nothing a little CPR won't f
On 9/10/2010 9:11 AM, Peter Rosin wrote:
> func_cygming_gnu_implib_p
> -
>
> 6. Dead code. Needs the sharedlib_from_linklib -> sharedlib_from_linklib_cmd
> typo fix. So, a previous testsuite deficiency that should not hold back this
> patch.
>
> func_cygming_gnu_implib_p a
On 9/9/2010 3:56 PM, Ralf Wildenhues wrote:
> I understand that you're doing a difficult bug hunt here, and 6/7 is the
> only unapplied patch of this series (right?). I've looked at 6/7 again,
> and conclude that it has a low chance of regressing.
I agree.
> If it makes things easier for you, th
On 9/9/2010 12:57 PM, Charles Wilson wrote:
> On 9/9/2010 4:59 AM, Peter Rosin wrote:
>> As discussed in that other thread, namely
>> http://lists.gnu.org/archive/html/libtool-patches/2010-09/msg00105.html
>> I accidentally broke MSYS/MinGW. Here's an improved version of
On 9/9/2010 4:59 AM, Peter Rosin wrote:
> As discussed in that other thread, namely
> http://lists.gnu.org/archive/html/libtool-patches/2010-09/msg00105.html
> I accidentally broke MSYS/MinGW. Here's an improved version of the patch
> shown in that message to fix the build issue. Sorry again.
>
>
ew that this patch was the cause of the regression, but
> I didn't understand that until I bisected the regression. Your comment
> a few message back:
>
> Den 2010-09-09 00:14 skrev Charles Wilson:
>> (However, there is an unfixed bug here; apparently something has changed
&
On 9/9/2010 3:19 AM, Peter Rosin wrote:
> Den 2010-09-09 06:18 skrev Charles Wilson:
>> Peter, a question about your current patch series: with it only
>> partially committed, do you expect errors? Are we waiting for some
>> other change upon which the current series depends
On 9/9/2010 5:47 AM, Peter Rosin wrote:
> Anyway, both fail in pretty much the same way for me:
>
> can't open the module tests/mdemo/foo1.la!
> error was: The specified module could not be found.
> can't open the module tests/mdemo/foo1!
> error was: The specified module could not be found.
> can
Peter, a question about your current patch series: with it only
partially committed, do you expect errors? Are we waiting for some
other change upon which the current series depends, before it all "just
works" again...or are things fubared now?
Right now, I'm seeing a regression just building lib
On 7/18/2010 9:07 PM, Charles Wilson wrote:
> linux->cygwin cross:
>
> old: 2 of 112 tests failed (12 tests were not run)
> FAIL: tests/demo-hardcode.test
> FAIL: tests/depdemo-relink.test
> new: AWFUL again -- but there's an explanatio
On 9/8/2010 5:52 PM, Peter Rosin wrote:
> Den 2010-09-05 23:29 skrev Ralf Wildenhues:
>> * Peter Rosin wrote on Sun, Sep 05, 2010 at 10:02:11PM CEST:
>>> Subject: [PATCH 6/7] Convert file name to toolchain format when invoking
>>> $NM.
>>>
>>> * libltdl/config/ltmain.m4sh (func_generate_dlsyms)
>>
On 9/8/2010 6:14 PM, Charles Wilson wrote:
> On 9/8/2010 5:52 PM, Peter Rosin wrote:
>> sharedlib_from_linklib_cmd, which is not used anywhere according
> # no lafile. user explicitly requested -dlpreopen .
> $sharedlib_from_link
On 9/8/2010 4:54 PM, Peter Rosin wrote:
> Hmmm, but @file makes it harder than necessary to debug on MSYS, since
> the automatic command line conversion make the n...@file branch work
> there. And the @file branch is probably bad for performance on MSYS too,
FYI, the patch that adds "@/looks/like/
On 9/5/2010 5:20 PM, Ralf Wildenhues wrote:
> Hi Peter,
>
> * Peter Rosin wrote on Sun, Sep 05, 2010 at 09:58:58PM CEST:
>> Subject: [PATCH 1/7] Add file name conversion from $build to toolchain.
>>
>> * configure.ac: Ensure to_tool_file_cmd is available to Makefile.
>> * libltdl/m4/libtool.m4 (_L
[meta-request: in the future, could you not use whatever option it is
that causes the entire patch message to be stored at attachment to the
actual message...this is a little awkward to reply-to:]
On 9/5/2010 3:58 PM, Peter Rosin wrote:
...which means all replies have to manually cut-n-paste-as-
FYI, I just proposed the following for MSYS (when launching "native"
apps, like the MinGW binutils/gcc, or MSVC tools):
http://thread.gmane.org/gmane.comp.gnu.mingw.msys/4820
2010.09.04 Charles Wilson <...>
* path.cc (msys_p2w): Support conversion of @file
argu
On 9/4/2010 4:52 AM, Peter Rosin wrote:
>
> If you are using -lfoo, then you *must* use 'compile' as well as cl
> does not know about the -l option. So, I was thinking that 'compile'
> instead of just transforming -lfoo into foo.lib would walk the library
> search path (in the same order as cl wou
On 9/3/2010 1:42 PM, Peter Rosin wrote:
> Den 2010-09-03 18:05 skrev Charles Wilson:
>> This way, non-libtool unixish makefiles could always use -lfoo,
>> regardless of whether they were linking to a static lib or dynamic lib.
>
> Well, -lfoo didn't work for both sta
On 9/3/2010 7:59 AM, Peter Rosin wrote:
> So, I'm now proposing this naming scheme instead:
>
> static lib: foo.lib
> shared lib: foo-2.dll
> import lib: foo.dll.lib
>
> which is a lot more consistent with the MinGW naming, i.e.:
>
> static lib: libfoo.a
> shared lib: libfoo-2.dll
> import
On 9/2/2010 5:08 PM, Eric Blake wrote:
> On 09/02/2010 03:00 PM, Charles Wilson wrote:
>> Two people worked on a single patch, or someone submitted it, and then
>> one of the people with commit access modified the patch slightly. The
>> GCS says you should do t
On 9/2/2010 3:05 AM, Gary V. Vaughan wrote:
> On 2 Sep 2010, at 12:40, Charles Wilson wrote:
>> 'Course, I notice that I screwed up the date in the ChangeLog. Could
>> the next person to commit a change to that file, please fix it?
>>
>> -2010-09-31 ...
On 9/2/2010 9:06 AM, Peter Rosin wrote:
> However, my previous suggestion with a naive_slashify instead of
> naive_backslashify doesn't work either since MSYS turns @c:/foobar into
> @c;c:\msys\1.0\foobar (or something similar, that was from memory) which
> we must avoid at all cost. cygpath -m (in
On 8/30/2010 4:20 PM, Ralf Wildenhues wrote:
> * Charles Wilson wrote on Mon, Aug 30, 2010 at 09:45:00PM CEST:
>> Thanks for the review.
>
> My pleasure.
Pushed as attached.
'Course, I notice that I screwed up the date in the ChangeLog. Could
the next person to commit a
On 9/1/2010 4:32 PM, Peter Rosin wrote:
> +AC_MSG_CHECKING([how to convert $build file names to toolchain format])
> +AC_CACHE_VAL(lt_cv_to_tool_file_cmd,
> +[#assume ordinary cross tools, or native build.
> +lt_cv_to_tool_file_cmd=func_convert_file_noop
> +case $host in
> + *mingw* )
> +case
On 9/1/2010 5:30 PM, Ralf Wildenhues wrote:
> * Peter Rosin wrote on Wed, Sep 01, 2010 at 10:33:59PM CEST:
>> * libltdl/config/ltmain.m4sh (func_mode_compile): Replace the
>> fix_srcfile_path hook with a call to func_to_tool_file.
>> * libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) [cygwin,mingw,pw32]
>
On 8/31/2010 10:53 PM, Gary V. Vaughan wrote:
> Does anyone else use the commit script?
>
> * clcommit.m4sh: Removed. This script was written to help keep
> ChangeLog and commit messages in sync when committing to CVS,
> and is an anachronism now that Libtool uses git.
>
> Okay to push?
>
> ---
On 8/30/2010 2:48 PM, Ralf Wildenhues wrote:
* Charles Wilson wrote on Mon, Aug 30, 2010 at 01:50:12AM CEST:
OK to push?
Looks fine to me too, only one or two issues are not markup or typo
nits (but I have been very nitpicky below).
I expected that. This is really only a first draft with
On 8/30/2010 12:32 AM, Gary V. Vaughan wrote:
>> Documentation updates for path conversion. Plus a missed
>> path<->file-name terminology correction.
>
> Awesome! Thanks for that. An interesting read.
>
>> OK to push?
>
> Please do. Two patches though - otherwise we have two independent
> cha
On 8/26/2010 2:26 AM, Peter Rosin wrote:
> This is my current queue of libtool patches. They need more work.
> In particular, I don't know if 0008-Slashify-instead-of-backslashify
> is even remotely acceptable. The subject has been up before and I
> think Chuck had some issue with it, but don't rem
On 8/29/2010 12:21 PM, Peter Rosin wrote:
> Den 2010-08-28 08:57 skrev Charles Wilson:
>> Rename file/path conversion functions
>
> You missed one instance here. Pushed the attached as obvious...
Thanks.
--
Chuck
* doc/libtool.texi (Platform quirks): Add new subsections
'Cross compiling' and 'File name/path conversion'.
* libltdl/config/ltmain.m4sh (func_convert_file_check): Update
comments and warning message.
func_convert_path_check): Update warning message.
---
Documentation updates for path conversion.
On 8/28/2010 8:10 PM, Ralf Wildenhues wrote:
> * Charles Wilson wrote on Sun, Aug 29, 2010 at 12:27:15AM CEST:
>> libltdl/m4/libtool.m4 (_LT_WITH_SYSROOT): Fix typo.
>> tests/sysroot.at: Search also for crt0.o to accommodate cygwin.
>>
>> OK to push?
>
> Sure.
Done.
--
Chuck
On 8/28/2010 8:10 PM, Ralf Wildenhues wrote:
> * Charles Wilson wrote on Sun, Aug 29, 2010 at 12:27:15AM CEST:
>> libltdl/m4/libtool.m4 (_LT_WITH_SYSROOT): Fix typo.
>> tests/sysroot.at: Search also for crt0.o to accommodate cygwin.
>> ---
>> Somehow this patch got drop
On 8/28/2010 6:38 PM, Vincent Torri wrote:
>> case ${with_sysroot} in #(
>> yes)
>>if test "$GCC" = yes; then
>> - lt_sysroot=`$GCC --print-sysroot 2>/dev/null`
>> + lt_sysroot=`$CC --print-sysroot 2>/dev/null`
>
> what is the interest of testing $GCC if you use $CC ?
$GCC != "gcc".
libltdl/m4/libtool.m4 (_LT_WITH_SYSROOT): Fix typo.
tests/sysroot.at: Search also for crt0.o to accommodate cygwin.
---
Somehow this patch got dropped when the sysroot branch
was merged. Rebased against master...
OK to push?
--
Chuck
libltdl/m4/libtool.m4 |2 +-
tests/sysroot.at |
On 8/28/2010 2:57 AM, Charles Wilson wrote:
> Ok, I've addressed all of the review comments, including the results of
> the four ***QQQ***estions. Quick-N-Dirty spot testing on native cygwin,
> native mingw, cygwin->mingw, linux->mingw, linux->cygwin all look good,
> so
On 7/18/2010 9:07 PM, Charles Wilson wrote:
Aaarrrgh. Sorry again for the messed-up date.
--
Chuck
* configure.ac: Ensure to_host_file_cmd is available to Makefile.
* TODO: Document QoI issue with file name conversion functions.
* libltdl/m4/libtool.m4 (_LT_PATH_CONVERSION_FUNCTIONS): New function
sets libtool variable $to_host_file_cmd, and employs cache.
(_LT_SETUP): Require it.
* tests/testsu
On 8/28/2010 11:43 AM, Vincent Torri wrote:
> On Sat, 28 Aug 2010, Charles Wilson wrote:
>> On 8/28/2010 9:21 AM, Ralf Wildenhues wrote:
>>> [__WINDOWS__, __CYGWIN__, _WIN32_WCE]: Define LT_DLSYM_CONST
>> I don't think __WINDOWS__ is the correct symbol; that is
On 8/28/2010 11:31 AM, Ralf Wildenhues wrote:
> * Charles Wilson wrote on Sat, Aug 28, 2010 at 05:13:38PM CEST:
>> On 8/28/2010 9:21 AM, Ralf Wildenhues wrote:
>>> [__WINDOWS__, __CYGWIN__, _WIN32_WCE]: Define LT_DLSYM_CONST
>> I don't think __WINDOWS__ is the
On 8/28/2010 9:21 AM, Ralf Wildenhues wrote:
> [__WINDOWS__, __CYGWIN__, _WIN32_WCE]: Define LT_DLSYM_CONST
I don't think __WINDOWS__ is the correct symbol; that is only defined by
Watcom C/C++. I think this should be changed to _WIN32 throughout.
See
http://predef.sourceforge.net/preos.html
On 8/27/2010 3:47 PM, Ralf Wildenhues wrote:
> * Charles Wilson wrote on Fri, Aug 27, 2010 at 08:49:24PM CEST:
>> As I said, I don't mind rebasing. I'll probably only test the result on
>> cygwin-native, mingw-native, and linux->mingw, and then push to master
On 8/27/2010 3:47 PM, Ralf Wildenhues wrote:
> * Charles Wilson wrote on Fri, Aug 27, 2010 at 08:49:24PM CEST:
>> However, once I have finished the requested changes above and the
>> rebasing (plus whatever comes of the four open ***QQQ***uestions), I
>> might ask for a 12 ho
On 8/27/2010 5:48 PM, Ralf Wildenhues wrote:
> * Charles Wilson wrote on Fri, Aug 27, 2010 at 10:23:31PM CEST:
>> Original:
>> real25m3.886s
>> user6m24.620s
>> sys 11m13.787s
>>
>> With the functions moved ahead of func_mode_compile:
>> r
On 8/27/2010 2:01 PM, Ralf Wildenhues wrote:
> * Charles Wilson wrote on Fri, Aug 27, 2010 at 06:35:31PM CEST:
>> Now, this is a little disturbing, since my -dlpreopen was supposed to
>> have fixed this;
>
> Would be good to fix, yes. On *nix, I'd be suggesting git bi
On 8/27/2010 12:54 AM, Ralf Wildenhues wrote:
> * Charles Wilson wrote on Thu, Aug 26, 2010 at 11:20:48PM CEST:
>> Also: I've said this before, but we can't use the m4
>> function_replace magic because we need to retain the ability for
>> users to override the c
On 8/26/2010 5:20 PM, Charles Wilson wrote:
> On 8/26/2010 4:18 PM, Ralf Wildenhues wrote:
>> Then, please just move the new functions where Peter needs them,
>> if they really need moving, that is.
>
> I deliberately placed them after func_compile and before func_link, f
On 8/26/2010 4:18 PM, Ralf Wildenhues wrote:
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -528,7 +528,8 @@ TESTS_ENVIRONMENT = MAKE="$(MAKE)" CC="$(CC)"
>> CFLAGS="$(CFLAGS)" \
>> CXX="$(CXX)" CXXFLAGS="$(CXXFLAGS)" CXXCPP="$(CXXCPP)" \
>> F77="$(F77)" FFLAGS="$(FFLAGS)" \
>> FC=
On 8/27/2010 2:10 PM, Ralf Wildenhues wrote:
> Another questions regarding this patch:
>
> Do you know whether all of the conversion functions are idempotent
> (f(f(x)) = f(x))? IOW, when the user passes names already converted,
> do we do the right things in all cases?
I'm pretty sure they are
1 - 100 of 523 matches
Mail list logo
