Closed Bryan-Turek closed 2 years ago
I believe that the Makefile
could be improved, but that doesn't explain why this works for me. What distribution of Linux are you using? Also, do you see the same issue with vintage_net_wifi
when building against an official Nerves system?
/etc/redhat-release
: CentOS Stream release 8
I had attempted to use an official release, but have version 23 of the Erlang OTP installed. I had stopped once I encountered the version mismatch between host/target. My custom system was branched from an official release that worked previously and on another development environment (mac osx), and with very little changes, I believed that it shouldn't have had an effect on the vintage_net_wifi build (mostly partitioning changes). That being said, I will install asdf
and swap between installed erlang versions to see if I can rebuild a hello_nerves
application with vintage_net_wifi
and see where that gets me.
I'm tempted to adjust the Makefile
to check if $PKG_CONFIG
is already set, since if it is, then the Makefile
really should use it.
If you're comfortable making this change, please send a PR. If not, I'll look into making it in the morning (it's getting late here).
I'm comfortable with submitting a PR, although i really feel like I am missing something. Mainly because:
pkg-config
should operate properly inside the Nerves system environment, although clearly doesn't in my case. Is the Nerves platform not behaving as intended in my environment? Ultimately, what is the desired outcome of which pkg-config
inside the Makefile within the Nerves environment? should It be pointing to /usr/bin/pkg-config
, or ~/.nerves/artifacts/custom_system-portable-X.X.X/host/usr/bin/pkg-config
?I had thought that both /usr/bin/pkg-config
and ~/.nerves/artifacts/custom_system-portable-X.X.X/host/usr/bin/pkg-config
should work the same and it shouldn't matter. Could there be a PKG_CONFIG
environment variable already set in your .bashrc
? Or perhaps there's a default built into /usr/bin/pkg-config
that's not being overridden by Nerves to set the search paths appropriately?
I just had a similar problem with pkg-config; In this case /usr/bin/pkg-config: symbol lookup error: /usr/bin/pkg-config: undefined symbol: pkgconf_cross_personality_deinit
I tracked it down to, as noted above, using /usr/bin/pkg-config
vs. ~/.nerves/artifacts/custom_system-portable-X.X.X/host/usr/bin/pkg-config
.
Further digging showed that it was being dynamically linked against ~/.nerves/artifacts/custom_system-portable-X.X.X/host/usr/lib/libpkgconf.so.3
Since my system pkg-config is 1.8.0 and the buildroot pkg-config is 1.6.3, this did not work.
I have a Makefile patch that makes it use /usr/bin/pkg-config
vs. ~/.nerves/artifacts/custom_system-portable-X.X.X/host/usr/bin/pkg-config
@ejc123 Do you have any idea why /usr/bin/pkg-config
is being dynamically linked to ~/.nerves/artifacts/custom_system-..../host/usr/lib/libpkgconf.so.3
? Rather than /usr/lib/libpkgconf.so.3
?
LD_LIBRARY_PATH is being set to ~/.nerves/artifacts/custom_rpi0-portable-1.18.0-dev/host/usr/lib
when I build with the custom Nerves system. When I build with the downloaded rpi0 target, LD_LIBRARY_PATH is empty.
Thanks for looking into this more.
Could you confirm that ~/.nerves/artifacts/custom_rpi0-portable-1.18.0-dev/host/usr/bin
is in your $PATH
and before your system paths? It is for me, and I'd think that would make the pkg-config
in the custom Nerves system get found.
My other thought is that the code that adds the host
directories to your $PATH
and $LD_LIBRARY_PATH
could be deleted completely. That would make using a custom system during development more similar to using it after it's been released. I'm highly leaning towards doing this, but I wanted to verify that something else wasn't going on.
Whatever is adding ~/.nerves/artifacts/custom_rpi0-portable-1.18.0-dev/host/usr/bin
to my $PATH
is adding it at the end.
What part of the code is responsible for adding these to $PATH
and $LD_LIBRARY_PATH
?
I changed the code to add the path is in the first commit in https://github.com/nerves-networking/vintage_net_wifi/issues/66. I don't use this, though, so could you verify that I did it right?
@jjcarstens - I may need your assistance if this doesn't work.
I verified that this change allows it to build; $PATH
has ~/.nerves/artifacts/custom_rpi0-portable-1.18.0-dev/host/bin
as the first entry and $PKG_CONFIG
is ~/.nerves/artifacts/custom_rpi0-portable-1.18.0-dev/host/bin/pkg-config
Great! Thanks for debugging and verifying the fix. I'd like to get another change in nerves_system_br
before the next release, but hopefully that won't take too long.
Hi,
I'm currently working on a nerves project that incorporates vintage_net_wifi within a custom nerves system layer. I ran into a unique issue where pkg-config appeared to unable to find a symbol that it was able to find when ran manually. In the Makefile the command
$(shell /usr/bin/pkg-config --cflags libnl-genl-3.0)
failed to return a valid path to the libnl3 header files. It appears the environment that was executingpkg-config
was unable to locate '.so' file that contains the 'pkgconf_pkg_dir_list_build' symbol to successfully run. Through debugging, I was able to determine that $PKG_CONFIG was already set, presumably by the nerves platform, and was able to work-around the issue by removing line 51 in the Makefile:PKG_CONFIG = $(shell which pkg-config)
.I've come to the conclusion that my development environment / configuration is not setup properly, though I've been unable to locate any configuration or setting that would resolve this issue. Especially considering I was able to get it to successfully build once. Any ideas?