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).
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 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).
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).
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).
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 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
