You are not logged in.
I am trying to build ardupilot on my arch. I can do so on Ubuntu. I am missing arm-linux-gnueabihf-pkg-config program on arch. There is compiler arm-linux-gnueabihf-gcc in AUR but for some reason is not bundled with arm-linux-gnueabihf-pkg-config. Is there any reason why it was done like that. And more importantly how can I get arm-linux-gnueabihf-pkg-config in my arch? Can you sketch PKGBUILD for me?
Last edited by crazySocket (2019-01-27 13:03:59)
Offline
That is because the program you are looking for is supposed to be a shellscript which
1) defines $PKG_CONFIG_LIBDIR as equal to the specific directory for your cross-compiler triple, which contains .pc files. That is to say, /usr/arm-linux-gnueabihf/lib/pkgconfig
2) exec pkg-config "$@"
On Arch Linux, the pkg-config implementation is in fact pkgconf, and it can additionally set PKG_CONFIG_SYSTEM_LIBRARY_PATH and PKG_CONFIG_SYSTEM_INCLUDE_PATH.
...
For details on how this works, Arch Linux has two supported architectures: i686-pc-linux-gnu (used in the [multilib] repository) and x86_64-pc-linux-gnu. You will notice that /usr/bin/i686-pc-linux-gnu-pkg-config and /usr/bin/x86_64-pc-linux-gnu-pkg-config therefore exist and are provided by the pkgconf package (along with /usr/bin/pkgconf, /usr/bin/pkg-config, and /usr/bin/pkg-config-32). All of these are that exact wrapper script with the exception of /usr/bin/pkgconf which all the rest are designed to execute after setting the necessary options.
It is the responsibility of a cross-compiler toolchain to ensure this wrapper script works. Most typically, this would be provided by packages like:
https://aur.archlinux.org/packages/aarc … kg-config/
https://aur.archlinux.org/packages/ming … kg-config/
https://aur.archlinux.org/packages/risc … kg-config/
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Ok so I did cheat the build system into believing arm-linux-gnueabihf-pkg-config is available by making a shell script with content
#!/bin/sh
# Simple wrapper to tell pkgconf to behave as a platform-specific version of pkg-config
# Platform: arm-linux-gnueabihf
: ${PKG_CONFIG_LIBDIR=}
: ${PKG_CONFIG_SYSTEM_LIBRARY_PATH=/usr/arm-linux-gnueabihf/lib}
: ${PKG_CONFIG_SYSTEM_INCLUDE_PATH=/usr/arm-linux-gnueabihf/include}
export PKG_CONFIG_LIBDIR PKG_CONFIG_SYSTEM_LIBRARY_PATH PKG_CONFIG_SYSTEM_INCLUDE_PATH
exec pkgconf "$@"
Yet when I try to compile static executable I get error
/usr/bin/arm-linux-gnueabihf-ld: cannot find -lstdc++
collect2: error: ld returned 1 exit status
Did my pkg-config script not make a cut? I see the file /usr/arm-linux-gnueabihf/lib/libstdc++.so. Even added -L/usr/arm-linux-gnueabihf/lib/ to the /usr/bin/arm-linux-gnueabihf-g++. What is wrong?
Offline
Why are you doing your best to avoid using a PKGBUILD ?
I've taken a quick peek and the riscv64 (3rd link) & aarch64 (1st link) mentioned by Eschwartz should be easy to adapt to arm-linux-gnueabihf architecture.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Offline
Why are you doing your best to avoid using a PKGBUILD ?
Because it is a trivial single shellscript. While I agree that files should be tracked using PKGBUILDs, this physically cannot be the problem the OP is having.
I've taken a quick peek and the riscv64 (3rd link) & aarch64 (1st link) mentioned by Eschwartz should be easy to adapt to arm-linux-gnueabihf architecture.
Of my three links, you chose the two which I consider philosophically wrong, and explicitly skipped the one which is done correctly.
There is an exceedingly good reason why pkg-config/pkgconf make these settings configurable -- there is no earthly reason to build the same binary a hundred times, once for every target triple that people use. It's a program that consists of:
1) predefined default paths that describe a native system, and cross-compiler environment variables to redefine these,
2) a parser for the .pc file format,
3) an option parser,
4) routines for combining the paths in #1 with the contents of the .pc file in #2
Absolutely none of this requires recompiling the default paths, and especially it makes no sense to cross-compile pkg-config itself to run on another target triple when the native triple works fine.. it is just a lot of pointless busy work...
@crazySocket,
without knowing what code you are trying to build or the exact command line being used, we cannot know... but pkg-config is merely supposed to help the build system learn what CFLAGS/LDFLAGS to use for dependencies, it cannot help if the build system does not actually use those everywhere that it needs to.
And libstdc++ doesn't exactly have a .pc file anyway. It's actually part of gcc-libs itself, and for the target triple arm-linux-gnueabihf it will be part of arm-linux-gnueabihf-gcc (that package doesn't split out gcc/gcc-libs).
gcc itself is supposed to use the builtin spec to locate its own internal libraries for you.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
For clarity :
My post #4 was entirely addressed to crazySocket.
Judging by Eschwartz reply, I should have made clearer WHY I posted what I did .
Attempt to clarify
first sentence
Why are you doing your best to avoid using a PKGBUILD ?
crazysocket, I have the impression you are not comfortable with makepkg and PKGBUILDs.
Is this correct and how can we help ?
2nd sentence
I've taken a quick peek and the riscv64 (3rd link) & aarch64 (1st link) mentioned by Eschwartz should be easy to adapt to arm-linux-gnueabihf architecture.
I have looked at the 3 examples posted by eschwartz and assessed which is most suited to guide someone not yet comfortable with makepkg / PKGBUILD.
- The mingw64 PKGBUILD looks complicated and deals with crosscompiling for a different OS, not a different architecture.
not suited.
- The other 2 PKGBUILDS are concise , short and do deal with crosscompiling for a different architecture.
suitable.
Disclaimer :
I did not choose the example pacakges and only judged them for the purpose described above.
I make no claim about their validity, quality, logical correctness , philosophical correctness, writing style or any other other aspect then the one(s) I specifcally mentioned.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Offline
Seeing pkg-config is configurable I agree there is no need to recompile for every architecture. However, since the entirety of my build failed I modified - as @Lone_Wolf suggested - PKGBUILD of aarch64-linux-gnu-pkg-config to compare. All I did was change one variable (_target). Unfortunately, the build still fails.
I guess @eschwartz is right the issue does not relate to pkg-config. Thanks for help. Marking this thread as solved.
Offline
That is because the program you are looking for is supposed to be a shellscript which
You will notice that /usr/bin/i686-pc-linux-gnu-pkg-config and /usr/bin/x86_64-pc-linux-gnu-pkg-config therefore exist and are provided by the pkgconf package (along with /usr/bin/pkgconf, /usr/bin/pkg-config, and /usr/bin/pkg-config-32). All of these are that exact wrapper script with the exception of /usr/bin/pkgconf which all the rest are designed to execute after setting the necessary options.
Hmm, seems they are not any more - all of these files are just symlinks to a pkgconf executable.
So why it has changed and what is the current approach to handle this?
Offline