Configure.in TARGET vs HOST

Hello,

Is AC_CANONICAL_TARGET / AC_CANONICAL_SYSTEM really required in the
configure.in of SDL (and also sdl.m4, or configure.in of SDL_image) ?

It seems to me that AC_CANONICAL_HOST is enough.

Julien

Le Wed, 15 Mar 2006 09:22:19 +0100
Julien Lecomte a ?crit:

Is AC_CANONICAL_TARGET / AC_CANONICAL_SYSTEM really required in the
configure.in of SDL (and also sdl.m4, or configure.in of SDL_image) ?

It seems to me that AC_CANONICAL_HOST is enough.

This is required for cross-compilation, where the host (which compiles
stuff) and target (which will run compiled stuff) systems are different.–
Patrice Mandin
WWW: http://pmandin.atari.org/
Programmeur Linux, Atari
Sp?cialit?: D?veloppement, jeux

sorry, but that’s incorrect

–build -> machine that compiles the stuff
–host -> machine that runs the stuff
–target -> machine to generate code for

in libsdl terms, --target has no meaning and so it should prob drop
AC_REQUIRE([AC_CANONICAL_TARGET]) from sdl.m4
-mikeOn Wednesday 15 March 2006 12:52, Patrice Mandin wrote:

Le Wed, 15 Mar 2006 09:22:19 +0100

Julien Lecomte a ?crit:

Is AC_CANONICAL_TARGET / AC_CANONICAL_SYSTEM really required in the
configure.in of SDL (and also sdl.m4, or configure.in of SDL_image) ?

It seems to me that AC_CANONICAL_HOST is enough.

This is required for cross-compilation, where the host (which compiles
stuff) and target (which will run compiled stuff) systems are different.

And also from the configure.in file; since SDL doesn’t generate code.

TARGET is, AFAIK, only for compilers, assemblers and such; not libraries.

JulienOn 15/03/2006 19:23, Mike Frysinger wrote:

On Wednesday 15 March 2006 12:52, Patrice Mandin wrote:

Julien Lecomte <julien at …net> a ?crit:

Is AC_CANONICAL_TARGET / AC_CANONICAL_SYSTEM really required in the
configure.in of SDL (and also sdl.m4, or configure.in of SDL_image) ?

It seems to me that AC_CANONICAL_HOST is enough.
This is required for cross-compilation, where the host (which compiles
stuff) and target (which will run compiled stuff) systems are different.

sorry, but that’s incorrect

–build -> machine that compiles the stuff
–host -> machine that runs the stuff
–target -> machine to generate code for

in libsdl terms, --target has no meaning and so it should prob drop
AC_REQUIRE([AC_CANONICAL_TARGET]) from sdl.m4

generally true … but there’s no reason you couldnt have a library generate
code :slight_smile:
-mikeOn Wednesday 15 March 2006 14:13, Julien Lecomte wrote:

TARGET is, AFAIK, only for compilers, assemblers and such; not libraries.

Think MinGW. Build = Linux, Host = Linux, Target = Windows.
Applies to gcc, linker, and libraries.

Also MinGW: Build = Linux, Host = Windows, Target = Windows.
Same library. But the generated gcc won’t run on linux, it’s
a windows app.

And MinGW again: Build = Windows, Host = Windows, Target= Windows.
When you try to built it on Windows with itself.

Don’t know how autoconf would handle Felix though …
it’s a cross-cross compiler (the compiler generates
C++ not objects files so another compiler is needed
as well). Felix adds a fourth platform, the Run platform.
This is why configuring for libs like SDL is rather tricky ;(

Anyhow bottom line is it certainly makes sense to
build SDL on Linux, creating an sdl.a archive,
and link it with your program using mingw gcc,
on Linux, to create an SDL application for Win32.
So the 3 categories apply to libraries too.
ESPECIALLY libraries like SDL where cross platform
development is likely … eg you’re building for an
Xbox, PS-2, or Nokia target.

build = format of scripts used to control build process,
names of tools on build platform.

host = format of the static library

target = processor code will execute on,
format of dynamic library.

Note that if your host and target are both linux,
but different processors, you must be VERY careful
to distinguish the TWO lib.so files you must generate.
One is needed to link an app against … the other is
needed to run the app. In case you think this is
rare you’re 1 million percent wrong … it is extremely
common! Just think AMD64 running both 32 and 64 bit
applications and realise you need to do this even
on the same Linux
. Same for Windows, but there
the distinction exists between the export lib
you link against building, and the DLL you use
at runtime.

I have grave doubts tools as weak as autoconf
can handle it (let alone a cross-cross compiler!).
That’s why Felix uses Python as a build tool.On Wed, 2006-03-15 at 14:27 -0500, Mike Frysinger wrote:

On Wednesday 15 March 2006 14:13, Julien Lecomte wrote:

TARGET is, AFAIK, only for compilers, assemblers and such; not libraries.

generally true … but there’s no reason you couldnt have a library generate
code :slight_smile:


John Skaller
Async PL, Realtime software consultants
Checkout Felix: http://felix.sourceforge.net

Anyhow bottom line is it certainly makes sense to
build SDL on Linux, creating an sdl.a archive,
and link it with your program using mingw gcc,
on Linux, to create an SDL application for Win32.
So the 3 categories apply to libraries too.
ESPECIALLY libraries like SDL where cross platform
development is likely … eg you’re building for an
Xbox, PS-2, or Nokia target.

build = format of scripts used to control build process,
names of tools on build platform.

host = format of the static library

target = processor code will execute on,
format of dynamic library.

no … the libc.a is in a format the cross-toolchain can read, but it still
contains objects for the $host. the format of archives (lib*.a) are the same
regardless of the architecture, the only thing that differs is the object
files contained inside of the archive.

you also seem to mixing the idea of static and dynamic libraries. if you link
against libsdl.a, there’s no point in having libsdl.so.

lets take your PS-2 example … on my amd64 linux box, i build a
cross-compiler:
–build=amd64 --host=amd64 --target=ps2
but this doesnt matter to libsdl which is configured with:
–build=amd64 --host=ps2

Note that if your host and target are both linux,
but different processors, you must be VERY careful
to distinguish the TWO lib.so files you must generate.
One is needed to link an app against … the other is
needed to run the app. In case you think this is
rare you’re 1 million percent wrong … it is extremely
common! Just think AMD64 running both 32 and 64 bit
applications and realise you need to do this even
on the same Linux
. Same for Windows, but there
the distinction exists between the export lib
you link against building, and the DLL you use
at runtime.

your example here is incorrect as well … on a multilib amd64 Linux system,
you have both 32bit and 64bit libs installed. you link and run against the
same libraries, there is no set of libraries you only link against and
another set you only run against, they are one and the same.
-mikeOn Wednesday 15 March 2006 20:12, skaller wrote:

–build -> machine that compiles the stuff
–host -> machine that runs the stuff
–target -> machine to generate code for

in libsdl terms, --target has no meaning and so it should prob drop
AC_REQUIRE([AC_CANONICAL_TARGET]) from sdl.m4

This is held over from wherever the script was adapted from…

Mike, you want to enter this in bugzilla?

Thanks!
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

done:
https://bugzilla.libsdl.org/show_bug.cgi?id=166
-mikeOn Wednesday 15 March 2006 21:19, Sam Lantinga wrote:

–build -> machine that compiles the stuff
–host -> machine that runs the stuff
–target -> machine to generate code for

in libsdl terms, --target has no meaning and so it should prob drop
AC_REQUIRE([AC_CANONICAL_TARGET]) from sdl.m4

This is held over from wherever the script was adapted from…

Mike, you want to enter this in bugzilla?