[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-dev] [PATCH] Fix build with libtool2

From: Gwenole Beauchesne
Subject: Re: [Gnash-dev] [PATCH] Fix build with libtool2
Date: Tue, 12 Jan 2010 23:41:03 +0100


Le 12 janv. 10 à 00:44, Gwenole Beauchesne a écrit :

Current trunk doesn't build on my Ubuntu 9.04 system with libtool 2.2.6a. Well, you don't strictly notice this problem with the original trunk but manual inspection of libbase/ reveals that some variables like noinst_HEADERS are only available in the libltdl1 path. Is this expected? This also means you can't generate a correct make dist with libtool2.

To be clearer, all noinst_HEADERS are in the libtool1 conditionals only. So, a make dist on a libtool2 system will not have the requested files.

BTW, it's no longer possible to run gnash within the build-dir on trunk either. gtk-gnash complains that: error while loading shared libraries: cannot open shared object file: No such file or directory

which is true, there is no The resulting gnash works with a make install but it's not really convenient. I will try to understand that tomorrow unless someone beats me.

This happens because I built gnash in a different builddir than $ (top_srcdir)/. e.g. objs.vaapi-agg/ in the $(top_srcdir)/

How to reproduce:
$ <extract/clone gnash sources from trunk>
$ mkdir objs.agg
$ cd objs.agg
$ CXXFLAGS="-Os -g -pipe" ../configure --enable-media=ffmpeg --enable- gui=gtk --enable-renderer=agg # or whatever confflags
$ make -jN

$ ./gui/gtk-gnash
will fail as I reported.

However, if you build from the top-level directory, there won't be any problem. It worked before (on 0.8.6), on the same Ubuntu 9.04 system. So, this indeed looks like libtool changes.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]