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 9f559243e8d9c2cc161acfab7ee4d274c7c422c5 (commit)
from
Den 2009-01-28 04:25 skrev Charles Wilson:
Peter Rosin wrote:
On MSYS/MinGW, stresstest.at now passes when Run tests with low
max_cmd_len, that fails on git master. On the other hand, cwrapper for
uninstalled executables fails at cwrapper.at:78 (both with and without
low max_cmd_len). It's the
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 case */
# define _P_WAIT0
#endif
_P_WAIT is guarded in MSVC's
Hi friends,
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 :)
- dynamic logs
http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00064.html
here I will probably make a
Den 2009-01-28 23:36, skrev Roumen Petrov:
Peter Rosin wrote:
Den 2009-01-28 04:25 skrev Charles Wilson:
Peter Rosin wrote:
[SNIP]
#ifndef _STAT_DEFINED
struct _stat
{
[SNIP]
};
#endif /* _STAT_DEFINED */
int _stat (const char *, struct _stat *);
[SNIP]
I think that we has to be careful
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 case */
# define _P_WAIT0
Peter Rosin wrote:
[SNIP]
This was all inside #ifdef __MINGW32__, which assumes msvcrt.dll, i.e.
compatible with MSVC 6, so we're safe. I think. Famous last words...
It seems to me that I misunderstood report failure and the case.
It start for ms compiler why #ifdef __MINGW32__ is now involved
Roumen Petrov wrote:
Peter Rosin wrote:
[SNIP]
This was all inside #ifdef __MINGW32__, which assumes msvcrt.dll, i.e.
compatible with MSVC 6, so we're safe. I think. Famous last words...
It seems to me that I misunderstood report failure and the case.
It start for ms compiler why #ifdef
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 denied
...
37.
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.
Signed-off-by: Dan Nicholson dbn.li...@gmail.com
---
libltdl/m4/libtool.m4 | 16 +++-
1 files changed, 15
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 consistently available for 64-bit Linux? If not,
should they be
On Wed, Jan 28, 2009 at 11:50 AM, Bob Friesenhahn
bfrie...@simple.dallas.tx.us 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.
On Wed, 2009-01-28 at 12:01 -0800, Dan Nicholson wrote:
If they follow the LSB, then they should be using lib64. However, you
can configure the linker any number of ways. I tried to get a patch to
glibc so this path could be determined, but it was rejected.
13 matches
Mail list logo
