John Levon wrote:
We have a C program which links to a C++ library, and we need to
tell automake to do the link in C++ mode to avoid undefined references
to the C++ standard library. How can we do it ?
The Makefile.am looks as follows :
---snip---
dist_sources = oprofiled.c opd_stats.c
Hi all!
For the protocol, I'm using am-1.7 and ac-2.54.
Is there a way to avoid using the dynamically-generated list of make
subrules (for every seperate object file) and simply have automake generate
a static list inside Makefile.in (that will be later copied into the
project's makefile)?
I
I wrote:
Is there a way to avoid using the ... [dependency tracking]...
Apologies. It *was* in the F*** manual :-). AUTOMAKE_OPTIONS =
no-dependencies in Makefile.am works as advertised.
My other question still stands though - regarding the neccesity/advantage
of calling header files by name
Due to insufficient quoting, install-sh fails for names (source or dest)
that contain spaces or some shell meta-characters. E.g.,
$ mkdir /tmp/x\ y
$ touch a\ b
$ bash install-sh 'a b' /tmp/x\ y
install-sh: line 150: [: /tmp/x: binary operator expected
mv: when moving multiple files,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear All,
Please forgive my posting about this topic. I have read the archive but
the answer posted:
http://sources.redhat.com/ml/automake/2000-06/msg4.html
does not solve my problem. Add to that the fact I am a beginner with
autotools!
I wish
On Sun, Nov 10, 2002 at 01:01:08PM +0100, Ralf Corsepius wrote:
You could always just add -lstdc++ to the oprofiled_LDADD variable.
This would be a fault, IMO.
I do not think getting gcc to link -lstdc++ is a good idea either, but
it doesn't have much more hack value than the solution you
Paul J wrote:
I wish to produce a library from two xdr files, datarpc.x and
visualrpc.x. Originally, the following GNU make commands produced the
correct output files which, by means of a hand crafted makefile (using
g++ as the compiler), compiled the rpcgen produced files into .o's:
Hi!
i just downloaded latest automake version and get the problem.
i have parser.yy file which is in the SOURCES list.
while making the project i got a error:
no target parser.cpp to build parser.lo (or something like this - i
can't remember the message exactly.)
The problem was solved by adding
Dixit John Levon levon at movementarian.org (2002-11-10 15:31):
A proper solution would be to use g++ to link the application. To
achieve this with automake, the easiest way is to convert the
main-application file to c++. In your case, renaming oprofiled.c to
oprofiled.cc would be
John Levon wrote:
On Sun, Nov 10, 2002 at 01:01:08PM +0100, Ralf Corsepius wrote:
You could always just add -lstdc++ to the oprofiled_LDADD variable.
This would be a fault, IMO.
Why?
I do not think getting gcc to link -lstdc++ is a good idea either, but
it doesn't have much more hack
Today I've been trying to learn automakeautoconf. Something I can't
figure out although it is the main reason I am investigating automake:
How do I set compiler flags based on the compiler? For example, g77
requires -fdollar-ok but Sun Fortran won't like that. How can I handle
that? How much
On Sun, Nov 10, 2002 at 06:50:47PM -0500, Earnie Boyd wrote:
I do not think getting gcc to link -lstdc++ is a good idea either, but
it doesn't have much more hack value than the solution you propose below
IMHO.
It's the hack that using g++ performs.
I do not believe there is any guarantee
On Sun, Nov 10, 2002 at 05:42:30PM -0500, Pierre Sarrazin wrote:
Another way to force automake to use g++ to link the application
seems to be to leave the .c alone, but to add a dummy.cc file to
the application's _SOURCES variable. The .c file is still compiled
by gcc.
This seems like the
This is an autoconf.at.gnu.org question...
Michael Lemke wrote:
Today I've been trying to learn automakeautoconf. Something I can't
figure out although it is the main reason I am investigating automake:
How do I set compiler flags based on the compiler? For example, g77
requires -fdollar-ok
Dixit John Levon levon at movementarian.org (2002-11-11 00:36):
On Sun, Nov 10, 2002 at 05:42:30PM -0500, Pierre Sarrazin wrote:
Another way to force automake to use g++ to link the application
seems to be to leave the .c alone, but to add a dummy.cc file to
the application's _SOURCES
Dixit John Levon levon at movementarian.org (2002-11-11 04:09):
clean-local:
rm -f dummy.cc
I did
CLEANFILES = dummy.cc
instead, which seems better
Oops, too much vodka. It's certainly better, even without the quotes.
--
Pierre Sarrazin sarrazip at sympatico . ca
On Sun, Nov 10, 2002 at 10:39:59PM -0500, Pierre Sarrazin wrote:
By the way, to avoid having the 'dist' target include dummy.cc in
the distributed source tarball, one has to say this:
whoops, forgot about this. thanks.
And to have 'clean' erase the generated dummy.cc:
clean-local:
Am Son, 2002-11-10 um 16.31 schrieb John Levon:
On Sun, Nov 10, 2002 at 01:01:08PM +0100, Ralf Corsepius wrote:
You could always just add -lstdc++ to the oprofiled_LDADD variable.
This would be a fault, IMO.
I do not think getting gcc to link -lstdc++ is a good idea either, but
it
Am Mon, 2002-11-11 um 00.50 schrieb Earnie Boyd:
John Levon wrote:
On Sun, Nov 10, 2002 at 01:01:08PM +0100, Ralf Corsepius wrote:
You could always just add -lstdc++ to the oprofiled_LDADD variable.
This would be a fault, IMO.
Why?
Because linking c++ is more than adding
On Mon, Nov 11, 2002 at 05:36:57AM +0100, Ralf Corsepius wrote:
1. Finding a way to compile your program (independently of automake).
You are using a library written in c++, therefore a general solution is
using g++ to _link_ your program, even if your main is written in C.
Rule of
20 matches
Mail list logo
