Hi,
With automake I can easily in the same build create executables linked
with non-PIC objects, shared libraries created from non-PIC objects,
and shared libraries created from PIC objects.
But is there a way to control the build to create the static libraries
from PIC objects?
There is a flag
Hi Kent,
* Kent Boortz wrote on Mon, Apr 03, 2006 at 12:24:31PM CEST:
>
> With automake I can easily in the same build create executables linked
> with non-PIC objects, shared libraries created from non-PIC objects,
> and shared libraries created from PIC objects.
But creating shared libraries f
Hi,
OK, my automake-driven project has managed to find a C++ compiler bug
due to optimization. Fortunately, the problem is only in a few files
in a subdir.
What I'd like to ensure is that compiler optimization is *not* used
by default for this subdirectory. But if I set AM_CXXFLAGS (e.g.
On Mon, Apr 03, 2006 at 04:29:29AM +0200, Ralf Wildenhues wrote:
> * Thomas Schwinge wrote on Fri, Mar 31, 2006 at 11:42:28AM CEST:
> >
> > In the old build system we had the very conventient feature that you
> > could `make progb' from the top level build directory and it would
> > automagically
Hi Bas,
* Bas Wijnen wrote on Mon, Apr 03, 2006 at 09:58:47AM CEST:
>
> In one of my projects, I use the nonrecursive approach, but I still have a
> Makefile.am per directory.
Yes, it's a good idea to group things this way (by using included
Makefile.am snippets)
> Automake obviously isn't buil
Hi,
Geoffrey Hutchison schrieb:
OK, my automake-driven project has managed to find a C++ compiler bug
due to optimization. Fortunately, the problem is only in a few files in
a subdir.
Erm, does it affect all C++ compilers, or just specific ones?
I suppose it is the latter only, so I'd sug
I'm having a problem with dist-bzip2 since on my makefile I have :
VPATH %.cc ./x ./xx ./xxx ...
bin_PROGRAMS = foo
foo_SOURCES = foo.cc bar.cc ...
When dist-bzip2 tries to copy some files not direcly in ./src it fails
miserably. Is there any solution for this? Or usually when using
multiple dirs
Hi Paulo,
* Paulo J. Matos wrote on Mon, Apr 03, 2006 at 06:29:19PM CEST:
> I'm having a problem with dist-bzip2 since on my makefile I have :
> VPATH %.cc ./x ./xx ./xxx ...
>
> bin_PROGRAMS = foo
> foo_SOURCES = foo.cc bar.cc ...
>
> When dist-bzip2 tries to copy some files not direcly in ./sr
On Mon, Apr 03, 2006 at 06:07:57PM +0200, Ralf Wildenhues wrote:
> Hi Bas,
Hi,
> > There's one major hack in there: automake doesn't support += on things like
> > bin_PROGRAMS, so I had to create temporary variables for it and do
> > bin_PROGRAMS = $(programs).
>
> This sounds awfully like a bug
On Apr 3, 2006, at 12:29 PM, Simon Richter wrote:
Erm, does it affect all C++ compilers, or just specific ones?
The latter, although it will probably take some time to figure out an
appropriate test case, since it also seems to involve linking to
certain versions of libxml2.
I suppose i
Hello,
On Mon, Apr 03, 2006 at 11:00:23AM -0400, Chris Pickett wrote:
> It could also be nice if autoreconf passed the -I flag to aclocal. I
> don't think it would matter if dirs not containing macros were in the
> list. Just an idea.
well, I'm not sure. autoconf -I might be used to find versi
On 03/04/06, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> Hi Paulo,
>
> * Paulo J. Matos wrote on Mon, Apr 03, 2006 at 06:29:19PM CEST:
> > I'm having a problem with dist-bzip2 since on my makefile I have :
> > VPATH %.cc ./x ./xx ./xxx ...
> >
> > bin_PROGRAMS = foo
> > foo_SOURCES = foo.cc bar.cc
12 matches
Mail list logo
