Jonathan Dumaresq wrote: > > and you have to make sure to set PKG_CONFIG_PATH > > This is where I dont' find many information.
Did you read pkg-config documentation? You should, it is very good and clear IMO, it gives a good understanding of what the tool does and how. > On my system this ENV var is not set to anything. That's fine. You normally do not use pkg-config for cross-compilation, right? > This var should be set to what ? /tmp/cross-compile/output ? Look at the man page for pkg-config. It is documented there, along with every other aspect of pkg-config. Xiaofan Chen wrote: > >> and you have to make sure to set PKG_CONFIG_PATH > > > > This is where I dont' find many information. > > I agree with you here. This is the difficult part and I do not see > a good solution to use pkg-config under Linux for cross compile > at least under the Linux distro I use: Ubuntu. Maybe the one > Peter uses (Gentoo) and probably Fedora has some nice > framework for MinGW cross. Gentoo might have some framework but there is really no need for one. pkg-config is a very simple tool that can be controlled to get desired results very easily. Please just look at what it does.. > It is the same situation to do the native build under MinGW. > pkg-config is kind of useless there. Yes, MinGW native build is not very different from crosscompiling; either way there exists no package manager. (But actually it seems like there exists one in MinGW now? The installer?) pkg-config is equally useful in both cases. pkg-config allows to separate software that has been built locally from the software that makes up the base system. Avoiding the mess of mixing base system (toolchain, etc) with locally built files in a single directory allows having a bit of structure in the system, regardless of Windows or Linux or SunOS or whatever. In your example you demonstrate copying various files into the toolchain bin and lib directories, which I personally strongly prefer to avoid. The (GNU) toolchain directories are intended for toolchain files and nothing else. I do not find it appropriate to install other packages there with the motivation that they are then found automatically by the toolchain. Those directories are > The way I solve the issue is to put the header file and lib > file to the respective location (eg: MinGW include and lib > directory. And this works very well for OpenOCD since it > only needs a few external library (eg: libusb-win32, libftdi > and libusb-1.0/libusbx). It is a mess. Why not use the tools to your advantage? Maintain a single prefix and use pkg-config; you will never have to bother with include paths or linker search paths again! It is actually incredibly simple. Andreas Fritiofson wrote: > > you have to make sure to set PKG_CONFIG_PATH > > PKG_CONFIG_PATH only *adds* to the default search path It's *prepended* to the default search path, so when set correctly it doesn't matter that pkg-config would still look through the default search path since the appropriate package has already been found, but I do agree that PKG_CONFIG_LIBDIR is the best choice. _PATH requires less typing though. :) //Peter ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
