<div dir="ltr">Hello List,<div><br></div><div>I'm a maintainer of a embedded Linux distribution and I am primarily responsible for each release's cross compiling toolchain, and any target packages that go into its sysroot. So the typical place to put a sysroot these days seems to be in the root of the toolchain, so we have something like this.</div>
<div><br></div><div><path to toolchain>:</div><div>./arm-unknown-linux-gnueabi</div><div>./bin    <--- All cross compilers and other utils targeting arm eabi go here</div><div>./include</div><div>./lib</div><div>
./libexec</div><div>./share</div><div>./sysroot <--- All third party libraries go here so we can use them for further dev</div><div><br></div><div>pkg-config is the closest thing we have to seamless configuration, building and linking with a toolchain in my opinion. I would like to ask your opinions on a few issues I feel exist in pkg-config.</div>
<div><br></div><div>Before pkg-config version 0.28, it seems that one has to export some environment variables to ensure that the pc file search path only included the relevant directories in the sysroot. I may be wrong but something along these lines:</div>
<div><br></div><div>$ unset PKG_CONFIG_PATH               # empty so no additional paths searched</div><div>$ PKG_CONFIG_LIBDIR=<path to toolchain>/sysroot/usr/lib/pkgconfig     # could include more paths</div><div>
$ export  PKG_CONFIG_LIBDIR</div><div>$ PKG_CONFIG_SYSROOT_DIR=<path to toolchain>/sysroot</div><div>$ export PKG_CONFIG_SYSROOT_DIR</div><div><br></div><div>Many maintainers would put that in a wrapper script (inside the bin dir of the toolchain) called arm-unknown-linux-gnueabi-pkg-config and call pkg-config at the end of the script. Therefore in an autotools project, you can configure the project to build correctly with:</div>
<div><br></div><div>$ export PATH=<path to toolchain>/bin:$PATH</div><div>$ PKG_CONFIG=arm-unknown-linux-gnueabi-pkg-config ./configure --host=arm-unknown-linux-gnueabi</div><div><br></div><div>The configure script will find <host tuple>-gcc (in my case arm-unknown-linux-gnueabi-gcc) if it was requested in the <a href="http://configure.ac">configure.ac</a> file...through the AC_PROG_CC macro. Does PKG_PROG_PKG_CONFIG do the same? If not, shouldn't it? Since pkg-config 0.28, we obtain an arm-unknown-linux-gnueabi-pkg-config program when we configure and build pkg-config with:</div>
<div><br></div><div>$ ./configure --host=arm-unknown-linux-gnueabi --prefix=/</div><div>$ make</div><div>$ make DESTDIR=<path to toolchain> install</div><div><br></div><div>Looking at the output of "<path to toolchain>/bin/arm-unknown-linux-gnueabi-pkg-config --list-all --debug" it is trying to find pc files in /lib/pkgconfig (and some others). If we change the way we build it:</div>
<div><br></div><div><div>$ ./configure --host=arm-unknown-linux-gnueabi --prefix=<path to toolchain></div><div>$ make</div><div>$ make install</div></div><div><br></div><div>Now "<path to toolchain>/bin/arm-unknown-linux-gnueabi-pkg-config --list-all --debug" is trying to find the pc files in <path to toolchain>/lib/pkgconfig (and some others). So it is still not searching for them in where I would have installed target packages (<the sysroot>/usr). So before I make this message a tutorial on how I think pkg-config works, let me compare it to GCC.</div>
<div><br></div><div>The GCC is configured and built with a build tuple, host tuple and target tuple. The build is usually something like x86_64-pc-linux-gnu and the host would also be x86_64-pc-linux-gnu if I was building my CROSS compiler for ARM. That allows me to run arm-unknown-linux-gnueabi-gcc on my x86_64 machine, the thing that tells GCC to produce objects for arm is the target (arm-unknown-linux-gnueabi). As you can see from the way I configured pkg-config, host arm-unknown-linux-gnueabi is wrong, but the build continues successfully if I don't have an arm-unknown-linux-gnueabi c compiler in the path. In my opinion, pkg-config should run on host and be used for target.</div>
<div><br></div><div>GCC would also have been configured with --with-sysroot=<path to toolchain>/sysroot, and GCC would then treat that directory as the root filesystem for the target, i.e. it is impossible that the c library would be found in /lib (gcc will only look in <sysroot>/lib and other standard paths).  The toolchain is also relocatable in this case (just the way GCC works), which means I can build a toolchain in /home/ben/toolchain and a guy called Tim can copy it to /home/tim/toolchain and it will still resolve...am I wrong that arm-unknown-linux-gnueabi-pkg-config would still be looking in the prefix /home/ben/toolchain? </div>
<div><br></div><div>So in summary, my ideal situation is:</div><div>$ ./configure --prefix=/ --target=arm-unknown-linux-gnueabi --with-relative-sysroot=/sysroot    # sysroot is given relative to the install prefix</div><div>
$ make</div><div>$ make DESTDIR=/home/ben/toolchain install</div><div>$ /home/ben/toolchain/bin/arm-unknown-linux-gnueabi-pkg-config --list-all</div><div>someCrazyArmLibrary.pc</div><div>...</div><div><Do not show me anything in /usr/lib/pkgconfig...even on Tim's machine></div>
<div><br></div><div>Thoughts?</div><div><br></div><div>Regards,</div><div>Ben Phillips</div></div>