Re: --build and --host

> "Henrique" == Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: Henrique> It also means Debian will need to fork config.guess Henrique> permanently so as to force autoconf stuff to build using the Henrique> correct host arch (since there seems to be no way to Henrique> sepecify a buil

Re: AC_CPLUSPLUS doesn't work

> "Stefan" == Stefan Seefeld <[EMAIL PROTECTED]> writes: Stefan> hi there, I'v run into another problem with autoconf 2.52: Stefan> at some point, I set the language to be used to C++, as I code Stefan> in C++ and want all tests to be performed with C++. Stefan> However, the language is aut

Re: --build and --host

On Mon, 04 Mar 2002, Akim Demaille wrote: > > "Henrique" == Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: > Henrique> It also means Debian will need to fork config.guess > Henrique> permanently so as to force autoconf stuff to build using the > Henrique> correct host arch (since ther

Autoconf 2.53

Any reason not to release now?

Re: Autoconf 2.53

> Any reason not to release now? What is the status of the f90 contributions? Is there any way they could get included? Kate -- Kate Hedström Arctic Region Supercomputing Center [EMAIL PROTECTED] University of Alaska, Fairbanks

Re: Autoconf 2.53

> From: Kate Hedstrom <[EMAIL PROTECTED]> > Date: Mon, 4 Mar 2002 08:44:16 -0900 > > What is the status of the f90 contributions? You can answer questions like that by grabbing the latest CVS version (e.g. from ). The ChangeLog* files are a g

Re: AC_TRY_RUN and cross-compiling

Paul Eggert wrote: > > > From: Dan Kegel <[EMAIL PROTECTED]> > > Date: Sun, 03 Mar 2002 10:02:14 -0800 > > > > configure should have an option, > > --emit-try-run, which would generate and compile a C program > > which, when compiled and run, would output environment > > settings which could be u

Re: AC_TRY_RUN and cross-compiling

> Date: Mon, 04 Mar 2002 10:38:00 -0800 > From: Dan Kegel <[EMAIL PROTECTED]> > Maybe configure would take a '--host-run-cmd' option which > would tell it how to run executables during TRY_RUN for > cross-compilation. Yes, that's the sort of thing that I'd like to see. Can you implement it? It

Re: AC_TRY_RUN and cross-compiling

Paul Eggert wrote: > > > Date: Mon, 04 Mar 2002 10:38:00 -0800 > > From: Dan Kegel <[EMAIL PROTECTED]> > > > Maybe configure would take a '--host-run-cmd' option which > > would tell it how to run executables during TRY_RUN for > > cross-compilation. > > Yes, that's the sort of thing that I'd l

Re: configure.in vs. configure.ac clash

On Sat, Mar 02, 2002 at 03:59:32PM +0100, Alexandre Duret-Lutz wrote: > >>> "gd" == Guido Draheim <[EMAIL PROTECTED]> writes: > > gd> while trying to create an rpm for the mp4h project, I jumped on the > gd> following problem: > > gd> - the toplevel configure has configure.ac > gd> - a subdi

cross-compiling question: static libraries and binaries to different places?

I'm cross-developing. I want to build a package that has both static libraries and binaries. The binaries should go to the target system; the libraries should stay on the build system. What do I pass to configure and to make? If I do configure --build=pentium-unknown-linux --host=@IXIA_K_ARCH@-u

Re: cross-compiling question: static libraries and binaries to different places?

--bindir vs. --libdir ? Es schrieb Dan Kegel: > > I'm cross-developing. I want to build a package > that has both static libraries and binaries. > The binaries should go to the target system; > the libraries should stay on the build system. > What do I pass to configure and to make? > > If I

Re: cross-compiling question: static libraries and binaries to different places?

You'd think so, but playing games like that might really confuse libtool. What I'd like to see is a fully-worked out example of how to use libtool, with both static and shared libraries, in a cross-compile situation, without the static libraries leaking out onto the target system. We may need to

Re: cross-compiling question: static libraries and binaries to different places?

, you want the shared libraries go to the target system during install, and the static libraries to stay. May I ask how do you expect the linker to resolve with the shared library if that one is remote? The static lib isn't the same, so, *hhmm* I am a bit confused. So far, I would ha

Re: cross-compiling question: static libraries and binaries to different places?

Here's what happens when you try to use --libdir. When doing builds into a staging area, you pass the path to the staging area to make as DESTDIR. So if DESTDIR is /foo, but you want libraries to go to /usr/lib, you're screwed; nothing you put into --libdir will make them go anywhere but a subd

Re: cross-compiling question: static libraries and binaries to different places?

Guido Draheim wrote: > > , you want the shared libraries go to the > target system during install, and the static libraries > to stay. Yes. Also, binaries should go to the target system. > May I ask how do you expect the linker to > resolve with the shared library if that one is >

Re: cross-compiling question: static libraries and binaries to different places?

Es schrieb Dan Kegel: > > Yes. Doc and headers would stay on the build system. > > > It is however > > uncertain, e.g. on some build hosts, you could not > > read the manpages, while they are needed on the target > > host. Or just the other way round, useless on the > > target host, and useful

Re: cross-compiling question: static libraries and binaries to different places?

Guido Draheim wrote: > > ... > > I don't think this does the trick, though. I can't see > > how it lets you install binaries and shared libs to a staging > > area for transfer to the target, and everything else to > > their final location on the build system, while making > > sure that libtool is

Re: cross-compiling question: static libraries and binaries to different places?

Es schrieb Dan Kegel: > > Guido Draheim wrote: > > > ... > > > I don't think this does the trick, though. I can't see > > > how it lets you install binaries and shared libs to a staging > > > area for transfer to the target, and everything else to > > > their final location on the build system,