Gary V. Vaughan wrote:
Hi Roumen,
On 22 May 2010, at 03:26, Roumen Petrov wrote:
Gary V. Vaughan wrote:
The Libtool Team is pleased to announce release candidate 2.2.7b of GNU
Libtool. If there are no serious deficiencies reported in this release,
it will be renumbered as 2.2.8 and re-released (otherwise, we'll fix
any problems and put out 2.2.7d first).
[SNIP]
I not sure that this is resolved :
"http://lists.gnu.org/archive/html/bug-libtool/2010-01/msg00028.html"
Can you confirm that the testcase at the end of this link still shows a
failure on Windows? I haven't used a Windows machine in almost a decade,
and don't have access to one.
I don't have windows host and for some test I must wait feedback from
friends.
I'm not sure that test case is only windows issue. Yes I know that
similar test pass on elf shared libraries. Right now I'm not able to
write test that fail on linux except the case described here
http://www.aleksey.com/pipermail/xmlsec/2010/008866.html
The patch that resolve issue for xmlsec is to move libxmlsec1.la as
dependend library at end:
libxmlsec1_openssl_la_LIBADD = \
- ../libxmlsec1.la \
$(OPENSSL_LIBS) \
$(LIBXSLT_LIBS) \
$(LIBXML_LIBS) \
+ ../libxmlsec1.la \
$(NULL)
This build against dependent libraries with and without la-files
(openssl is one of them) and one of attachments is difference : libtool
output before and after patch.
Is the problem due to Windows searching for DLLs along $PATH? And, if so, do
you know whether the current directory is always searched first irrespective
of the PATH setting?
If your answers are 'yes' and 'no' respectively, I might be able to look
into the wrapper script code and figure out why PATH is not being set
correctly. In either case, I'll be happy to accept a patch :)
As I post here
http://lists.gnu.org/archive/html/bug-libtool/2009-12/msg00037.html
very simple issue is to prepend to PATH value of EXE_PATH_VALUE first
and LIB_PATH_VALUE second.
Cheers,
Roumen
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool