On 2013-04-10 15:03, Marc-André Lureau wrote:
Interesting, I didn't know (and I wouldn't try, I am cross-compiling guy :) However, this isn't going to be enough, there are many variables in .pc which may contain path.
Yeah, projects not re-using the prefix variable when defining other paths in their .pc files probably need to be fixed. For example a .pc.in file having: prefix=@prefix@ exec_prefix=@exec_prefix@ libdir=@libdir@ includedir=@includedir@ which after evaluation by autoconf's config.status produces the following .pc file: prefix=/c/some_project/prefix exec_prefix=${prefix} libdir=${exec_prefix}/lib includedir=${prefix}/include is OK.
Also projects not using pkg-config have the same problems.
Those should obviously be fixed to use pkg-config, right? ;)
Doing a grep under fedora-mingw sys-root reveals that there are many binaries that refer to hardcoded path too.
Also needs to be fixed imho... One issue like this I never got to resolve was hardcoded paths in perl scripts (for GTK-Doc iirc). Python makes this easy by providing the __file__ builtin, but how to do something like that in perl has been evading me... Oh well, nobody said supporting "relocatable installs" for software usually only expecting to be installed in "/" was going to be easy :P
In general, it's not going to work if I try to reuse those cross-builds for doing native build. Fortunately, by now, most of the runtime is working natively, but there are still corner-cases (this is still one of the first thing you need to fix when porting a lib/app)
Yeah, it seems there will always be corner-cases, unfortunately... mvg, Dieter _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list