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 opd_kern
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 (*t
With cvs code from now:
% sh bootstrap
Bareword "am__installdirs" not allowed while "strict subs" in use at ./automake.tmp
line 4742.
BEGIN not safe after errors--compilation aborted at ./automake.tmp line 7682.
# Deal with installdirs target.
sub handle_installdirs ()
{
$output_rules .=
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, la
-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 p
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:
Auto
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 pa
Dixit John Levon (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 sufficient.
>
> This seems
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 v
Today I've been trying to learn automake&autoconf. 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 gua
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 th
This is an autoconf.at.gnu.org question...
Michael Lemke wrote:
Today I've been trying to learn automake&autoconf. 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 (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 variable. The .c file is
Dixit John Levon (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
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
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
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
21 matches
Mail list logo
