[CMake] CMAKE_TOOLCHAIN_FILE / testing with 'wine'

[Hendrik Sattler]

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...

HS