[CMake] CMAKE_TOOLCHAIN_FILE / testing with 'wine'

[Hendrik Sattler]

Am Mittwoch, 20. August 2008 00:19:32 schrieb Mathieu Malaterre:
> On Wed, Aug 20, 2008 at 12:16 AM, Hendrik Sattler
>
> <post at hendrik-sattler.de> wrote:
> > Am Dienstag, 19. August 2008 23:55:30 schrieb Mathieu Malaterre:
> >> On Tue, Aug 19, 2008 at 11:46 PM, Hendrik Sattler
> >>
> >> <post at hendrik-sattler.de> wrote:
> >> > Am Dienstag, 19. August 2008 23:17:18 schrieb Alexander Neundorf:
> >> >> On Tuesday 19 August 2008, Hendrik Sattler wrote:
> >> >> > Am Dienstag, 19. August 2008 22:24:12 schrieb Mathieu Malaterre:
> >> >> > >   Did you figure out a way to install 32bits debian package in
> >> >> > > the /emul/ia32 subdirectory ? How did you install your target
> >> >> > > system environment. On my debian box, the ia32-libs package works
> >> >> > > somewhat ok, but it only provide the runtime 32bits libs (not the
> >> >> > > include file for instance).
> >> >> >
> >> >> > The include files do not differ (they are architecture-independent)
> >> >> > for normal projects. Why would you want to install a second set?
> >> >>
> >> >> Because they could differ, e.g. different versions or whatever.
> >> >
> >> > Not in a distribution like Debian. Well unless you are using unstable
> >> > as it has a reason to be called like that.
> >> > For other cases, the e.g ia32- packaes on amd64 have the same version.
> >> > And in this case, they do not differ.
> >> >
> >> > On other systems where you have 32bit and 64bit libraries mixed (e.g.
> >> > Solaris), you also only have _one_ include directory.
> >>
> >> Very impressive... this means that at any level of inclusion none of
> >> the include files has any system specific declaration (even gcc
> >> header!).
> >
> > gcc is not normal software. It actually needs to be specially ported to
> > architectures and thus is always special. But the compiler knows where to
> > find its include files, so you rarely need to worry about that, do you?
> >
> > Unless headers are generated at build time of the software that you
> > depend on, how could they possibly be different? libz doesn't, just to
> > use your example...
>
> Ok I have two questions then for you:
> 1. what is the flag for gcc to generate byte code for powerpc
> (-mcpu=powerpc is deprecated)

You have a gcc that was compiled with that as target? Gcc-4.3 manpage mentions 
nothing about this option being deprecated.

> 2. what is the difference between the gcc package and gcc-multilib. If
> gcc package still exist and has not been replaced by gcc-multilib,
> there must be a reason...

gcc-multilib is an addition to the gcc package, that allows you to actually 
link the 32bit binaries on your 64bit installation (or the other way round).

HS