On Tue, 2006-08-08 at 20:18 +0800, Tzu-Chien Chiu wrote:
Hello, Ralf.
I found gcc and newlib don't use AM_ENABLE_MULTILIB, instead
TARGET_SUBDIR is set.
Pardon, they (and binutils) use it.
AM_ENABLE_MULTILIB is used in library subdir configure scripts
(*/configure.[ac|in]), not inside of
Hello,
Ralf Corsepius has answered the question about AM_ENABLE_MULTILIB,
and then, on Thu, Sep 21, 2006 at 09:52:25AM +0200, he wrote:
I need to build *both* the native and the cross-compiled library
at the same time (one-time configure script and make), rather than
*either one* of
Hello,
I apologize if this has been answered somewhere. Ive read the book and
searched the archives.
My situation is this:
Im porting a large code-base from windows to linux, and attempting to
use autotools to do so. The code in SVN is essentially one big tree of
somewhat related modules --
Hello Ryan,
* Ryan McDougall wrote on Thu, Sep 21, 2006 at 11:40:37AM CEST:
Im porting a large code-base from windows to linux, and attempting to
use autotools to do so. The code in SVN is essentially one big tree of
somewhat related modules -- lets call them foo, bar, etc (Projects under
Thank you. You're right. It has nothing to do with multilib.
I've read configure.ac and Makefile.am of texinfo. Here is how it works.
When cross-compiling, the same configure script is run twice for all
sub-directories of source directory. Makefile.am, however, selectively only
builds some or
On Thu, 2006-09-21 at 21:36 +0800, Tzu-Chien Chiu wrote:
Thank you. You're right. It has nothing to do with multilib.
I've read configure.ac and Makefile.am of texinfo.
I am not familiar with texinfo's sources
Here is how it works.
When cross-compiling, the same configure script is run
On Thu, 2006-09-21 at 13:32 +0200, Ralf Wildenhues wrote:
Hello Ryan,
* Ryan McDougall wrote on Thu, Sep 21, 2006 at 11:40:37AM CEST:
Im porting a large code-base from windows to linux, and attempting to
use autotools to do so. The code in SVN is essentially one big tree of
somewhat
On Thu, 2006-09-21 at 13:32 +0200, Ralf Wildenhues wrote:
The second approach will enable you to
make libA.la
in the toplevel directory. Otherwise, there is nothing that prevents
you from adding your own targets a la
A:
cd src/A $(MAKE) $(AM_MAKEFLAGS) libA.la
.PHONY: A
* Ryan McDougall wrote on Fri, Sep 22, 2006 at 02:54:21AM CEST:
On Thu, 2006-09-21 at 13:32 +0200, Ralf Wildenhues wrote:
* Ryan McDougall wrote on Thu, Sep 21, 2006 at 11:40:37AM CEST:
1) If you prefer recursive makefiles then you can have each directory
create one (or a number of)
* Ryan McDougall wrote on Fri, Sep 22, 2006 at 04:10:40AM CEST:
The problem with this is that with this method that I have to manually
specify the dependencies, right?
A: foo
cd src/A $(MAKE) $(AM_MAKEFLAGS) libA.la
.PHONY: A
foo:
cd src/foo $(MAKE) $(AM_MAKEFLAGS)
On Fri, 2006-09-22 at 04:34 +0200, Ralf Wildenhues wrote:
You should keep in mind that the convenience archives will end up in
total (i.e., all their symbols, not just needed ones) in the resulting
module.
This is a good point, thank you. Do you have any more information
* Ryan McDougall wrote on Fri, Sep 22, 2006 at 04:51:41AM CEST:
On Fri, 2006-09-22 at 04:34 +0200, Ralf Wildenhues wrote:
The Libtool manual has more details about this (but it's arguably a bit
cryptic about convenience archives). I'm not sure what you need to
know.
Since Im leaning
Mike Melanson wrote:
It's possible that I'm chasing after the wrong solution. This is a more
specific problem:
* I have a proprietary program that I am trying to build to run on a
wide variety of Linux/x86-based distributions.
* The build process links against libstdc++.so.6 on the
13 matches
Mail list logo
