I am using the autotools in combination with GNU Bison and Flex. In
particular I am using the %glr directive in my bison file (parse.y).
Everything works fine, except that when I run 'make', 'ylwrap' is
invoked which runs 'bison -y -d' on 'parse.y' producing 'y.tab.h' and
'y.tab.c'. 'ylwrap' then r
Hello Erwin,
* Erwin Brandenberger wrote on Wed, May 27, 2009 at 09:33:49AM CEST:
>
> OS: Ubuntu 9.04
> IDE: KDE
>
> Project HC is Program and not a Library. Why it uses libtool ? Any help ?
>
> Making all in HC
> /bin/bash ../../libtool --tag=CXX --mode=link g++ -DRUN_UNIX -DRUN_LINUX -g
> -O2
On Wed, 27 May 2009, Erwin Brandenberger wrote:
OS: Ubuntu 9.04
IDE: KDE
Project HC is Program and not a Library. Why it uses libtool ? Any help ?
It seems that the libtool used has a bug on your system or the libtool
has been delivered improperly (e.g. mixing files from multiple libtool
ve
l-recursive] Error 1
make: *** [all] Error 2
*** Exited with status: 2 ***
--
View this message in context:
http://www.nabble.com/KDE-linking-problem-with-automake-projects-tp23737527p23737527.html
Sent from the Gnu - Automake - General mailing list archive at Nabble.com.
Hi Ralf,
I'm very sorry for cross sending the question to 2 or more lists.
Thank you very much for helping me solve the problem so rapidly.
Also thank you for reminding me. I just didnt know which one could
work.
It wont happen again. :)
Cheers,
Erming.
Ralf Wildenhues wrote:
Hi
Hi Erming,
Please, next time don't cross post a question to so many lists.
Just one is enough.
* Erming Pei wrote on Wed, Apr 12, 2006 at 03:07:45PM CEST:
> [EMAIL PROTECTED] gtkmm]$ automake -a -c
> Deep recursion on subroutine "Automake::read_am_file" at
> /usr/bin/automake line 7254, line 1
Hi,
Sorry to bother.
I tried to use automake to generate Makefile. But it kept reports as
following:
[EMAIL PROTECTED] gtkmm]$ aclocal;autoconf
[EMAIL PROTECTED] gtkmm]$ automake -a -c
Deep recursion on subroutine "Automake::read_am_file" at
/usr/bin/automake line 7254, line 1.
Can't locate C
Hi Ralf,
sorry for this late answer, but I was snowboarding this weekend and did not
checked my emails til now...
Ralf Wildenhues schrieb:
I think pointing outside the build tree like this is a hack that can
break. Not sure though, but I would not rely on that to work.
I need this lit
Hi Steve,
* Steve Kreyer wrote on Thu, Feb 16, 2006 at 08:57:32PM CET:
> Ralf Wildenhues schrieb:
>
> >Did configure enable dependency tracking? If yes, which type?
> >
> Ok that was it.
> I did not invoke automake with the -i option, so automatic
> dependency tracking was enabled :)
Well. De
Hi,
Ralf Wildenhues schrieb:
Hi Steve,
Did configure enable dependency tracking? If yes, which
type?
Ok that was it.
I did not invoke automake with the -i option, so automatic
dependency tracking was enabled :)
But one question arise:
Even if auto dependency tracking was enabled, i di
Hi Ralf,
thanks for your reply.
Ralf Wildenhues <[EMAIL PROTECTED]> schrieb am 16.02.06 10:04:44:
> No, I for one don't have a crystal ball. ;-)
Sorry for my less verbose information output :)
> Yes. You need to show us the Makefile.am's involved (and maybe we'll ask for
> more files later),
Hi Steve,
* Steve Kreyer wrote on Wed, Feb 15, 2006 at 06:08:06PM CET:
>
> I have some problems compiling my project with make.
> When i call make for 2nd time in topsrcdir, make does compile the
> sources which are located in src from scratch, even if they have not
> modified. When i call mak
Hi,
I have some problems compiling my project with make.
My directory structur is as follows:
topsrcdir/src/
topsrcdir/src/regex
topsrcdir/src/tidy
When i call make for 2nd time in topsrcdir, make does compile the
sources which
are located in src from scratch, even if they have not modified.
Hi Adnan,
* Adnan Shaheen wrote on Wed, Jan 04, 2006 at 10:28:01AM CET:
>
> I wrote a manual makefile and it compiles every thing without any problem.
> Than I used the automake and compiled the same project, with one file
> that was used to seek on hard disk, it gives me the following error.
>
Hi all, I was first writing makefile for my project manually, But then
some body told me about the automake process, since then I ve been
using the automake utility to compile and build my projects
I wrote a manual makefile and it compiles every thing without any problem.
Than I used the automake
Hi Stephen,
* Stephen Ellwood wrote on Thu, Sep 08, 2005 at 01:16:15AM CEST:
>
> Im currently writing a fairly nifty software project that makes use of GNU
> autotools extensively, although in a very basic way. My aim is to create a
> package manager in the style of RPM via automake. Im aiming
Hi.
Im currently writing a fairly nifty software project that makes use of GNU
autotools extensively, although in a very basic way. My aim is to create a
package manager in the style of RPM via automake. Im aiming to create both a
*distro AND platform independent* package manager for Linux.
On Tue, Oct 26, 2004 at 04:35:26PM +0200, Peter Simons wrote:
> Alexandre Duret-Lutz writes:
>
> > It occured to me that maybe you were trying to use
> > $(LIBOBJS) outside of libgetopt/Makefile.am. Don't.
> > $(LIBOBJS) is expected to be used only in the directory
> > holding the substitute so
Alexandre Duret-Lutz writes:
> It occured to me that maybe you were trying to use
> $(LIBOBJS) outside of libgetopt/Makefile.am. Don't.
> $(LIBOBJS) is expected to be used only in the directory
> holding the substitute sources.
So I need to add a Makefile.am _and_ and a configure.ac file
to t
On Tue, Oct 26, 2004 at 02:43:26PM +0200, Alexandre Duret-Lutz wrote:
> On Tue, Oct 26, 2004 at 02:01:18PM +0200, Peter Simons wrote:
> > Alexandre Duret-Lutz writes:
> >
> > >> AC_LIBOBJ(libgetopt/getopt)
> > >> AC_LIBOBJ(libgetopt/getopt1)
> >
> > > AC_LIBOBJ([getopt])
> > > AC_LIBOBJ([getopt
On Tue, Oct 26, 2004 at 02:01:18PM +0200, Peter Simons wrote:
> Alexandre Duret-Lutz writes:
>
> >> AC_LIBOBJ(libgetopt/getopt)
> >> AC_LIBOBJ(libgetopt/getopt1)
>
> > AC_LIBOBJ([getopt])
> > AC_LIBOBJ([getopt1])
>
> Then automake / autoconf won't find the files:
>
> configure.ac:173: require
Alexandre Duret-Lutz writes:
>> AC_LIBOBJ(libgetopt/getopt)
>> AC_LIBOBJ(libgetopt/getopt1)
> AC_LIBOBJ([getopt])
> AC_LIBOBJ([getopt1])
Then automake / autoconf won't find the files:
configure.ac:173: required file `./getopt1.c' not found
configure.ac:173: required file `./getopt.c' no
>>> "Peter" == Peter Simons <[EMAIL PROTECTED]> writes:
[...]
Peter> AC_LIBOBJ(libgetopt/getopt)
Peter> AC_LIBOBJ(libgetopt/getopt1)
[...]
Peter> but these paths aren't right, because the compiled
Peter> objects will be placed in
Peter> ./getopt.o
Peter> ./getopt1.o
Peter> ..., not in the
Hi,
in a project of mine, I ship versions of getopt and
getopt_long for backwards compatibility with older systems.
I test for the existence of these functions in the OS with
Autoconf, and if I don't find them I define:
if test "x$have_getopt_h" != "xyes" -o "x$have_getopt" != "xyes"; then
Hello,
I have the following problem with automake/libtool:
I am writing a software which supports dynamic loading of shared libraries
using libltdl. In order to test this feature, I need to create a shared
library whose sole purpose is to be dynamically loaded by a program
run by the '
> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
Gary> Don't forget that 1.4-p2 is simply a branch of the 2 year old
Gary> 1.4 with a small number of commonly reported bugs fixed. If the
Gary> fault you are seeing was fixed in mainline CVS after 1.4 was
Gary> released, you could backpo
Thanks, Gary! That may be it - the problem does not exist with CVS
automake at 1.4e with a top of ChangeLog:
2001-03-12 Pavel Roskin <[EMAIL PROTECTED]>
* tests/Makefile.am (XFAIL_TESTS): Remove cond3.test, it passes
now.
2001-03-12 Akim Demaille <[EMAIL PROTECTED]>
Hi Harlan,
Don't forget that 1.4-p2 is simply a branch of the 2 year old 1.4 with a
small number of commonly reported bugs fixed. If the fault you are seeing
was fixed in mainline CVS after 1.4 was released, you could backport that fix
to branch-1-4 in case 1.4-p3 arrives before 1.5 =)O|
Che
I'll make a better report as soon as I can.
The following problem is back:
% make
...
make[2]: Entering directory `/backroom/ntp4/A.whimsy/librsaref'
make[2]: *** No rule to make target `librsaref.a.c', needed by `librsaref.a.o'.
...
Makefile.am:
...
nodist_librsaref_a_SOURCES = \
desc
There is a small problem with automake-1.4 that is no longer present
in the development reasons.
There is a weird interaction with some versions of ksh that make the
generated recursive clean rules fail. Namely, the error from within
the loop propagates outside the loop and makes the whole
30 matches
Mail list logo
