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 a228f07a8ffb9610c070203de04ea2242755a71e (commit)
from
* Charles Wilson wrote on Sat, Jun 27, 2009 at 05:40:40PM CEST:
lt~obsolete.m4 supplies only empty, non-functional aliases for old,
public libtool macros that have been removed. It currently has this:
m4_ifndef([AC_LIBTOOL_RC], [AC_DEFUN([AC_LIBTOOL_RC])])
Can that line stay,
* libltdl/m4/libtool.m4: Add reminder comment concerning
aclocal-1.4 backwards compatibility.
* libltdl/m4/lt~obsolete.m4: Remove unnecessary AC_DEFUN.
---
Pushed as pre-approved.
--
Chuck
ChangeLog |8
libltdl/m4/libtool.m4 |1 +
libltdl/m4/lt~obsolete.m4 |
* libltdl/m4/libtool.m4 (_LT_SYS_DYNAMIC_LINKER): Fix handling
of dos-style paths when parsing $CC -print-search-dirs output.
---
It appears that this particular behavior has been broken for quite some time.
Currently, libtool mangles $CC -print-search-dirs badly on mingw:
Charles Wilson wrote:
* libltdl/m4/libtool.m4 (_LT_SYS_DYNAMIC_LINKER): Fix handling
of dos-style paths when parsing $CC -print-search-dirs output.
---
Currently running regression tests on MSYS-1.0.12 + mingw-4.4.0-dw2 (TDM
version).
OK to push, if no regressions from earlier behavior
Vincent Torri wrote:
On MSYS-1.0.12 with gcc-4.4.0dw2 (TDM):
1.0.12 ?? There is only 1.0.11 RC (on the mingw.org wiki) afaik. Where
did you get that version ?
You're right. It's 1.0.11 and 1.0.10, not 1.0.12 and 1.0.11. Sorry,
it's late.
--
Chuck
Hello Charles,
* Charles Wilson wrote on Sun, Jun 28, 2009 at 12:54:59AM CEST:
The best I could come up with is this: IN the source code for the object, do
- top of file -
#if defined(BUILDING_MY_LIBRARY) defined(DLL_EXPORT)
stuff
#endif
- end of file -
This way, the
Ralf Wildenhues wrote:
* Charles Wilson wrote on Sun, Jun 28, 2009 at 12:54:59AM CEST:
Is there a better way?
Not that I know of. The current code might cause the object list for
the static library to be a larger set than that for the shared library
(because it won't add objects compiled
I ran in to a problem using libtool to generate both shared and static
libraries with convenience archives (on cygwin, but I believe this is
cross-platform). Working with git-master xz utils, with some local
patches, I saw the following:
/bin/sh ../../libtool --tag=CC --mode=link gcc
On Sun, 28 Jun 2009, Charles Wilson wrote:
So, when we get around to linking the actually installable library, both
the DLL and the static' archive contain the same .o's -- the ones
compiled with the pic flags -DDLL_EXPORT and -DPIC.
This is a problem, because now the static archive contains
10 matches
Mail list logo
