Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).
On Sun, May 23, 2010 at 11:11 AM, Ralf Wildenhues wrote: > * Alon Bar-Lev wrote on Sat, May 22, 2010 at 11:13:50AM CEST: >> On Sat, May 22, 2010 at 12:04 PM, Ralf Wildenhues wrote: >> > * Alon Bar-Lev wrote on Sat, May 22, 2010 at 09:44:46AM CEST: >> >> If I read your response correctly, all is needed is to set: >> >> lt_cv_deplibs_check_method="pass_all" >> >> For mingw hosts. >> >> >> >> But I am no expert in libtool, and it is a complex set of macros. >> >> All I know that in the final result libtool script setting: >> >> deplibs_check_method="pass_all" >> >> >> >> Makes it work. >> > >> > But breaks other things on this system. >> >> Can you please outline [logically] a solution for achieving this >> without breaking other things? >> If you give me a hint I can check it out and produce another solution. > > Not easy, because I haven't analyzed the issues that show up when > setting pass_all. I know it breaks a few testsuite tests (and I fear > it breaks more things that we don't test in our testsuite), but it's > been a while and I haven't been taking good notes back then. It might > be that some of the libtool logic is flawed wrt. the w32 semantics. Will windows be supported or not? I've gone a long way in order to convince people of using autoconf/automake/libtool also to create windows binaries. It is great to have single build system for all platforms... And now that we have the mingw-w64 project which revived mingw development it should be great! However, the lack of proper windows support in libtool is a major obstacle. > >> Linking between DLL and static library is valid in this platform. > > There were some arguing that it shouldn't be done out of > consistency/portability reasons: users could come to expect that this > would be possible everywhere. I'm not sure where I stand here; > certainly, the testsuite failures encountered provide the more stringent > argument. PIC static linking with shared objects is also portable... Thanks, Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).
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
Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).
* Alon Bar-Lev wrote on Sat, May 22, 2010 at 11:13:50AM CEST: > On Sat, May 22, 2010 at 12:04 PM, Ralf Wildenhues wrote: > > * Alon Bar-Lev wrote on Sat, May 22, 2010 at 09:44:46AM CEST: > >> If I read your response correctly, all is needed is to set: > >> lt_cv_deplibs_check_method="pass_all" > >> For mingw hosts. > >> > >> But I am no expert in libtool, and it is a complex set of macros. > >> All I know that in the final result libtool script setting: > >> deplibs_check_method="pass_all" > >> > >> Makes it work. > > > > But breaks other things on this system. > > Can you please outline [logically] a solution for achieving this > without breaking other things? > If you give me a hint I can check it out and produce another solution. Not easy, because I haven't analyzed the issues that show up when setting pass_all. I know it breaks a few testsuite tests (and I fear it breaks more things that we don't test in our testsuite), but it's been a while and I haven't been taking good notes back then. It might be that some of the libtool logic is flawed wrt. the w32 semantics. > Linking between DLL and static library is valid in this platform. There were some arguing that it shouldn't be done out of consistency/portability reasons: users could come to expect that this would be possible everywhere. I'm not sure where I stand here; certainly, the testsuite failures encountered provide the more stringent argument. > Maybe accept "current ar archive" file type will perform better? Sorry, I don't understand this suggestion. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).
On Sat, 22 May 2010, Gary V. Vaughan wrote: 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? Yes, Windows uses PATH equivalently to LD_LIBRARY_PATH except that it does always search the directory containing the executable first. I don't remember when the current directory is tried, and it may depend on the version of Windows. When tests are run, the current directory is rarely the directory containing the DLLs. Windows Vista 64 bit and Windows 7 add additional new rules (related to manifests) that we will start needing to worry about. The problem is not fixed yet as far as I am aware. It certainly plagues GraphicsMagick. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).
* Adam Mercer wrote on Fri, May 21, 2010 at 07:23:38PM CEST:
> Just updated one of my projects to use libtool-2.2.7b and configure
> now fails with:
>
> configure: error: conditional "am__fastdepCXX" was never defined.
> Usually this means the macro was only invoked conditionally.
>
> in configure.ac I was checking for a C++ compiler if a given option
> was used, i.e.:
>
> # boinc requires a c++ compiler
> if test "${boinc}" = "true" ; then
> AC_PROG_CXX
> fi
>
> Always checking for a C++ compiler makes the error go away. Are
> conditional checks like this bad?
FWIW, this is caused/exposed by (quoting NEWS):
- Fix long standing bug that caused compiler checks for Fortran and
C++ compilers to run twice.
I think the fix is right, and you've found a good workaround already,
too. However, it might cause issues for quite a few more packages out
there. I'm not sure what the best thing to do would be, but at the
least documenting it more prominently would seem prudent.
Cheers,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).
On Fri, May 21, 2010 at 3:22 AM, Gary V. Vaughan wrote:
> GNU Libtool hides the complexity of using shared libraries behind a
> consistent, portable interface. GNU Libtool ships with GNU libltdl,
> which hides the complexity of loading dynamic runtime libraries
> (modules) behind a consistent, portable interface.
Windows regression.
When linking with libstdc++ which is static library.
libtool-2.2.6b - complains but creates a shared library.
libtool-2.2.7b - complains and does not create a shared library.
Why linking with libstdc++? One of the static archives uses C++.
Why not use CXX? As the sources are C only.
Regards,
Alon.
configure.ac
---
AC_PREREQ([2.63])
AC_INIT([test1], [0])
AC_CONFIG_SRCDIR([f.c])
AC_CONFIG_HEADERS([config.h])
AC_CONFIG_MACRO_DIR([m4])
AM_INIT_AUTOMAKE
AC_PROG_CC
LT_INIT([win32-dll])
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
---
Makefile.am
---
AUTOMAKE_OPTIONS = foreign 1.10
ACLOCAL_AMFLAGS = -I m4
lib_LTLIBRARIES = libf.la
libf_la_SOURCES = f.c
libf_la_LDFLAGS = $(AM_LDFLAGS) -no-undefined
libf_la_LIBADD = -lstdc++
---
f.c
---
int f(void) {
return 0;
}
---
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).
On Sat, May 22, 2010 at 12:04 PM, Ralf Wildenhues wrote: > Hello, > > please don't Cc: autotools-announce on discussions. Thanks. Sorry. > * Alon Bar-Lev wrote on Sat, May 22, 2010 at 09:44:46AM CEST: >> If I read your response correctly, all is needed is to set: >> lt_cv_deplibs_check_method="pass_all" >> For mingw hosts. >> >> But I am no expert in libtool, and it is a complex set of macros. >> All I know that in the final result libtool script setting: >> deplibs_check_method="pass_all" >> >> Makes it work. > > But breaks other things on this system. Can you please outline [logically] a solution for achieving this without breaking other things? If you give me a hint I can check it out and produce another solution. Linking between DLL and static library is valid in this platform. Maybe accept "current ar archive" file type will perform better? Thanks, Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).
Hello, please don't Cc: autotools-announce on discussions. Thanks. * Alon Bar-Lev wrote on Sat, May 22, 2010 at 09:44:46AM CEST: > If I read your response correctly, all is needed is to set: > lt_cv_deplibs_check_method="pass_all" > For mingw hosts. > > But I am no expert in libtool, and it is a complex set of macros. > All I know that in the final result libtool script setting: > deplibs_check_method="pass_all" > > Makes it work. But breaks other things on this system. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).
On Sat, May 22, 2010 at 9:46 AM, Gary V. Vaughan wrote: > Hi Alon, > > On 22 May 2010, at 13:02, Alon Bar-Lev wrote: >> On Fri, May 21, 2010 at 3:22 AM, Gary V. Vaughan wrote: >>> >>> GNU Libtool hides the complexity of using shared libraries behind a >>> consistent, portable interface. GNU Libtool ships with GNU libltdl, >>> which hides the complexity of loading dynamic runtime libraries >>> (modules) behind a consistent, portable interface. >> >> >> >> I don't think [1] was solved. >> >> [1] http://www.mail-archive.com/libtool@gnu.org/msg12013.html > > Thanks for the ping. However I haven't used a Windows machine in almost > a decade and don't have access to one, but I'd be happy to accept a patch. You don't have to access one, as this is exactly what I am trying to achieve, cross compile Windows binaries on Linux. > Although I've slipped the deadlines I set myself at the top of this thread: > http://www.mail-archive.com/libtool@gnu.org/msg12059.html a little already, > I still plan to put Libtool-2.2.8 out within a week (or two at most), just > so long as no one reports significant breakage or regression that make it > worse than 2.2.6. > > And then Libtool-2.2.10 a month (or two at most) later. > > If your pet bugs aren't patched in time for 2.2.8, there's still time to > feed a patch to us in time for 2.2.10. > > Cheers, > -- > Gary V. Vaughan (g...@gnu.org) > If I read your response correctly, all is needed is to set: lt_cv_deplibs_check_method="pass_all" For mingw hosts. But I am no expert in libtool, and it is a complex set of macros. All I know that in the final result libtool script setting: deplibs_check_method="pass_all" Makes it work. If you have some other though and you want me to test, I will be happy to. Regards, Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).
Hi Alon, On 22 May 2010, at 13:02, Alon Bar-Lev wrote: > On Fri, May 21, 2010 at 3:22 AM, Gary V. Vaughan wrote: >> >> GNU Libtool hides the complexity of using shared libraries behind a >> consistent, portable interface. GNU Libtool ships with GNU libltdl, >> which hides the complexity of loading dynamic runtime libraries >> (modules) behind a consistent, portable interface. > > > > I don't think [1] was solved. > > [1] http://www.mail-archive.com/libtool@gnu.org/msg12013.html Thanks for the ping. However I haven't used a Windows machine in almost a decade and don't have access to one, but I'd be happy to accept a patch. Although I've slipped the deadlines I set myself at the top of this thread: http://www.mail-archive.com/libtool@gnu.org/msg12059.html a little already, I still plan to put Libtool-2.2.8 out within a week (or two at most), just so long as no one reports significant breakage or regression that make it worse than 2.2.6. And then Libtool-2.2.10 a month (or two at most) later. If your pet bugs aren't patched in time for 2.2.8, there's still time to feed a patch to us in time for 2.2.10. Cheers, -- Gary V. Vaughan (g...@gnu.org) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).
On Fri, May 21, 2010 at 3:22 AM, Gary V. Vaughan wrote: > > GNU Libtool hides the complexity of using shared libraries behind a > consistent, portable interface. GNU Libtool ships with GNU libltdl, > which hides the complexity of loading dynamic runtime libraries > (modules) behind a consistent, portable interface. I don't think [1] was solved. [1] http://www.mail-archive.com/libtool@gnu.org/msg12013.html ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).
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. 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 :) Cheers, -- Gary V. Vaughan (g...@gnu.org) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).
Gary V. Vaughan wrote: GNU Libtool hides the complexity of using shared libraries behind a consistent, portable interface. GNU Libtool ships with GNU libltdl, which hides the complexity of loading dynamic runtime libraries (modules) behind a consistent, portable interface. 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"; Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).
On Fri, May 21, 2010 at 14:01, Gary V. Vaughan wrote:
Gary
> In the end AC_PROG_CXX is not very time consuming, so I'd recommend
> something more along the lines of (untested - from memory):
>
> AC_PROG_CXX
> AM_CONDITIONAL([BUILD_BOINC], [test "x${boinc}" = xtrue])
>
> and then in Makefile.am
>
> if BUILD_BOINC
> add boinc decls here...
> end
Thanks Gary, that seems a much better way to do it.
Cheers
Adam
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).
Hi Adam,
On 22 May 2010, at 00:23, Adam Mercer wrote:
> On Thu, May 20, 2010 at 19:22, 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).
>
> Just updated one of my projects to use libtool-2.2.7b and configure
> now fails with:
>
> configure: error: conditional "am__fastdepCXX" was never defined.
> Usually this means the macro was only invoked conditionally.
Did you upgrade only libtool? I'd be surprised if that was the actual
cause of this error. AFAICT, it's a longstanding issue with Automake.
Automake appends an AM_CONDITIONAL to AC_PROG_CXX, and is then unhappy
when it's expanded inside the shell test, but never actually executed.
You might be able to work around it by adding "no-dependencies" to
AM_INIT_AUTOMAKE, although of course, in that case you'll lose automated
dependency tracking.
> in configure.ac I was checking for a C++ compiler if a given option
> was used, i.e.:
>
> # boinc requires a c++ compiler
> if test "${boinc}" = "true" ; then
> AC_PROG_CXX
> fi
In the end AC_PROG_CXX is not very time consuming, so I'd recommend
something more along the lines of (untested - from memory):
AC_PROG_CXX
AM_CONDITIONAL([BUILD_BOINC], [test "x${boinc}" = xtrue])
and then in Makefile.am
if BUILD_BOINC
add boinc decls here...
end
Cheers,
--
Gary V. Vaughan (g...@gnu.org)
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).
On Thu, May 20, 2010 at 19:22, Gary V. Vaughan wrote:
Hi
> 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).
Just updated one of my projects to use libtool-2.2.7b and configure
now fails with:
configure: error: conditional "am__fastdepCXX" was never defined.
Usually this means the macro was only invoked conditionally.
in configure.ac I was checking for a C++ compiler if a given option
was used, i.e.:
# boinc requires a c++ compiler
if test "${boinc}" = "true" ; then
AC_PROG_CXX
fi
Always checking for a C++ compiler makes the error go away. Are
conditional checks like this bad?
Cheers
Adam
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).
Hey, On Fri, 21 May 2010, Gary V. Vaughan wrote: GNU Libtool hides the complexity of using shared libraries behind a consistent, portable interface. GNU Libtool ships with GNU libltdl, which hides the complexity of loading dynamic runtime libraries (modules) behind a consistent, portable interface. 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). Just a note: i tried to compile a program for Windows CE (using cegcc) and it works, now (well, it worked with the git version, so...) thank you Vincent Torri ___ http://lists.gnu.org/mailman/listinfo/libtool
