Re: help cross compiling again

["Marcelo Armengot Iborra" <Marcelo Armengot uv es>]

> (This list is for discussion about development of GTK+ itself. Your
> message is more for gtk-app-devel-list.)
> 
> Marcelo Armengot writes:
>  > -Ic:/devel/target/gtk+-2.10.7/include/gtk-2.0 
>  > -Ic:/devel/target/gtk+-2.10.7/lib/gtk-2.0/include 
>  > -Ic:/devel/target/atk-1.12.3/include/atk-1.0 
>  > -Ic:/devel/target/cairo-1.2.6/include/cairo 
> 
> (etc)
> 
> This indicates that you are using .pc files that are intended for use
> with a Windows build of pkg-config.
> 
> If you use them for cross-compilation, you need to edit the prefix
> variable in the .pc files from the GTK+, atk, cairo, Pango and GLib
> developer packages to correspond to the actual location where you
> unpacked ("installed") them.
> 
> As distributed, the .pc files from the Win32 developer packages on
> ftp.gtk.org and ftp.gnome.org have prefix variables pointing to
> directories that do not exist on your (or any other)
> machine. (Typically c:/devel/target/<package-name>.) This is as
> intended, and *not* a bug. Read on.
> 
> If you think it *is* a bug, what would you then suggest should be the
> value of prefix in the distributed .pc files? How could I know in
> advance where you are going to unpack the developer package? This is
> especially true on Windows, where one definitely never should assume
> that *any* path exists on the end-user machines. Not all machines even
> have a C: drive.
> 
> Everything I build and distribute for Windows is supposed to be freely
> unpackable in any random location. My run-time packages (libraries,
> executables) are even supposed to be installable in directories with
> any random Unicode characters in their pathnames, even spaces and
> characters not in the system codepage, like Greek on an English
> Windows installation. If this doesn't work, *that* is a
> bug. (pkg-config unfortunately doesn't work with spaces in path
> names. This is a cross-platform feature of it.)
> 
> When running on Windows, pkg-config automatically knows to determine
> the actual installation location of a package from where the .pc file
> was found.
> 
> For instance, if somebody unpacks the Win32 GTK+ developer package
> under the folder Z:\foo\dev, the gtk+-win32-2.0.pc file will be
> Z:\foo\dev\lib\pkgconfig\gtk+-win32-2.0.pc. pkg-config will disregard
> the prefix assignment in the .pc file and instead use Z:\foo\dev as
> prefix for that .pc file.
> 
> On Unix, pkg-config doesn't do this. So you will have to edit the .pc
> files.
> 
> Alternatively, maybe pkg-config should do that prefix override magic
> on Unix, too? If you think so, please file a bug against it.
> 
> Or, somebody could take the Win32 developer packages and repackage
> them into packages for their favourite Linux distro that would install
> in a fixed location, with the .pc files already correct.
> 
> --tml
> 
> 


Ok, thak you very much
i understand everything better (is not a joke), well i changed it but
the problem persists...
question is: he say me that he dont found lgtk-win32-2.0 and probably
this library is not in my machine (anywhere) because with "find" tool i
dont find it too.

But if i download and charge in my folder structure i will be capable of
telling to my machine where is...
but please, what about this library???