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 th
* 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 I
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 info
* 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_M
* 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 numbe
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
>
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
> >
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
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 all
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
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 -- le
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
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
13 matches
Mail list logo
