This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via d356bfc32fd946b3a62eec391fefa9e1714ff53d (commit)
from
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via 3e0beef8eb35a734514d5c4871f19a32c5edb145 (commit)
from
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via 18c603141ee49f71c49c0e54f9f831316c023b91 (commit)
from
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via b93a3db892cb3203ec5cfe10cb673999b13e13d2 (commit)
from
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via 13ef1b34b7a17af22769817f243c347b4412a890 (commit)
from
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via 0980a3993a6138895d4884f92ff9764d426b148d (commit)
from
Hi!
As reported by Roumen Petrov [1], the cwrapper test is somewhat
disfunctional.
Ok to push the attached?
Cheers,
Peter
[1] http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00201.html
2009-01-29 Peter Rosin p...@lysator.liu.se
Make modified libtool script in cwrapper
* Peter Rosin wrote on Thu, Jan 29, 2009 at 09:02:57AM CET:
2009-01-29 Peter Rosin p...@lysator.liu.se
Make modified libtool script in cwrapper test executable
* tests/cwrapper.at: Make modified libtool script executable.
Report by Roumen Petrov.
This is obvious, thanks.
Den 2009-01-28 23:44 skrev Peter Rosin:
Den 2009-01-28 16:13 skrev Charles Wilson:
Peter Rosin wrote:
Maybe, here are the errors:
So, I guess these declarations should do it (untested):
int _setmode (int, int);
int _spawnv (int, const char *, const char * const *);
#ifndef _P_WAIT /* just in
Peter Rosin wrote:
I have:
$ gcc -v
Reading specs from C:/MinGW/bin/../lib/gcc/mingw32/3.4.2/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as
--host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads
--disable-nls
Den 2009-01-29 11:49 skrev Charles Wilson:
What version of mingw-runtime are you using? (I'm not sure which version
I have; its from a bundle I put together about a year ago; I can get to
the docu for that bundler later today. It's probably mingw-runtime-3.14).
Something prior to [1]
On Thu, 29 Jan 2009, Peter Rosin wrote:
Den 2009-01-29 11:49 skrev Charles Wilson:
What version of mingw-runtime are you using? (I'm not sure which version
I have; its from a bundle I put together about a year ago; I can get to
the docu for that bundler later today. It's probably
Hi Akim,
* Akim Demaille wrote on Tue, Jan 06, 2009 at 09:24:32AM CET:
Le 6 janv. 09 à 07:48, Ralf Wildenhues a écrit :
Are those the only distcc/ccache-induced failures?
Yes, I had no other failures.
Thanks, and sorry for the delay. In the meantime, the localization code
has seen some
Den 2009-01-29 18:26 skrev Bob Friesenhahn:
On Thu, 29 Jan 2009, Peter Rosin wrote:
Den 2009-01-29 11:49 skrev Charles Wilson:
What version of mingw-runtime are you using? (I'm not sure which version
I have; its from a bundle I put together about a year ago; I can get to
the docu for that
Den 2009-01-29 18:56, skrev Ralf Wildenhues:
* Peter Rosin wrote on Thu, Jan 29, 2009 at 06:53:48PM CET:
But maybe, just maybe, you don't have a desperate need to do
-std=c89 -Werror :-)
Guys, if all you're working around is -Werror, then stop right now.
Just eliminate -Werror from $LTCC
Hi Akim,
* Akim Demaille wrote on Wed, Jan 28, 2009 at 04:43:56PM CET:
Some of my patches are waiting for approvals or comments.
I do understand that it requires time to process them, I
just want to make sure they aren't forgotten :)
Thanks for the reminder. I think I had them all on my
* Ralf Wildenhues wrote on Mon, Jan 19, 2009 at 09:47:54PM CET:
The long line in ltmain.m4sh is actually necessary in order for
libtool --version
to work correctly. Will address in a followup patch.
OK to push?
I've pushed this now.
Cheers,
Ralf
func_version copes with
* Ralf Wildenhues wrote on Sat, Jan 24, 2009 at 03:52:49PM CET:
Please note that there is an alternative short-hand, in that you
can use (among others) the following equivalently:
libtool --mode=execute PROG [ARGS]...
libtoolexecute PROG [ARGS]...
libtoolexe PROG
Peter Rosin wrote:
Den 2009-01-29 18:56, skrev Ralf Wildenhues:
* Peter Rosin wrote on Thu, Jan 29, 2009 at 06:53:48PM CET:
But maybe, just maybe, you don't have a desperate need to do
-std=c89 -Werror :-)
Guys, if all you're working around is -Werror, then stop right now.
Just eliminate
Peter Rosin wrote:
Den 2009-01-29 00:45 skrev Roumen Petrov:
snip
I'm sure that I test libtool in mingw-cross env. after Charles add
cwrapper test. Now I repeat the test N# 37(cwrapper) in verbose mode and
the results is:
...
/at-groups/37/test-source: line 73: ./libtool: Permission
Peter Rosin wrote:
Den 2009-01-29 11:49 skrev Charles Wilson:
What version of mingw-runtime are you using? (I'm not sure which version
I have; its from a bundle I put together about a year ago; I can get to
the docu for that bundler later today. It's probably mingw-runtime-3.14).
Something
Bob Friesenhahn wrote:
My own MinGW install dates from the 2002/2003 time frame. :-)
At the time MinGW/MSYS was a simple install. Nowadays it seems to be
all jumbled up so I have not tried to cross the hurdle of an update.
Yes, the MinGW download site is a disaster, thanks to SF
Roumen Petrov wrote:
I think that we has to be careful about structure _stat and version of
msvcrt (=8.0) - it depend from definition of time_t 32/64 bit and the
size is deferent depending from an another macro. May be wrapper has to
include MSVC headers.
This is all moot. We (libtool's
Akim Demaille wrote:
Le 29 janv. 09 à 19:22, Ralf Wildenhues a écrit :
For this one I'd prefer if Charles and/or Peter took care of it, they
have a bunch of changes in this area and some discussion going on.
Actually, I'd prefer to just be able to say go! once y'all have agreed
on a common
Ralf Wildenhues wrote:
* Akim Demaille wrote on Wed, Jan 28, 2009 at 04:43:56PM CET:
- nuke warnings in the wrappers
The patch at the end of
http://lists.gnu.org/archive/html/libtool/2008-12/msg00069.html
For this one I'd prefer if Charles and/or Peter took care of it, they
have a
Ralf Wildenhues wrote:
* Peter Rosin wrote on Thu, Jan 29, 2009 at 06:53:48PM CET:
But maybe, just maybe, you don't have a desperate need to do
-std=c89 -Werror :-)
Guys, if all you're working around is -Werror, then stop right now.
Just eliminate -Werror from $LTCC $LTCFLAGS and be done
Hi Charles,
* Charles Wilson wrote on Fri, Jan 30, 2009 at 05:34:08AM CET:
See earlier reply in this thread for why we don't need to worry about
any other magic MSVC macros. So, I think the only remaining
cleanup-warnings patch for the cwrapper is this:
diff --git
On Wed, Jan 28, 2009 at 01:50:51PM -0600, Bob Friesenhahn wrote:
On Wed, 28 Jan 2009, Dan Nicholson wrote:
When the ABI is 64-bit on Linux ELF, add /lib64 and /usr/lib64 to the
system library path so that an RPATH is not added when using libraries
from these directories.
Are these libraries
Dan Nicholson wrote:
On Wed, Jan 28, 2009 at 01:50:51PM -0600, Bob Friesenhahn wrote:
On Wed, 28 Jan 2009, Dan Nicholson wrote:
When the ABI is 64-bit on Linux ELF, add /lib64 and /usr/lib64 to the
system library path so that an RPATH is not added when using libraries
from these directories.
29 matches
Mail list logo
