I’m trying to run Agora. To that end, I’ve added gcc, memcached, and the C headers for memcached to my config:
gcc
memcached
libmemcached # C/C++ library
But when I try to build Agora server I get an error, the punchline of which is this:
In file included from src/_pylibmcmodule.c:34:
src/_pylibmcmodule.h:42:10: fatal error: libmemcached/memcached.h: No such file or directory
42 | #include <libmemcached/memcached.h>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
To test whether I’d get a similar result, I wrote a little C program:
#include <stdio.h>
#include <libmemcached/memcached.h>
int main() {
printf("Hello, World!");
}
and sure enough, I do:
[jeff@jbb-dell:~/gcc-test]$ gcc gcc-test.c
gcc-test.c:2:10: fatal error: libmemcached/memcached.h: No such file or directory
2 | #include <libmemcached/memcached.h>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
i didn’t say it was the ‘code’, i was saying it may be related to the build system. These things are two very different domains. How code is compiled from source to code, is very different to how the program is linked, assembled and packaged.
I appreciate your help and apologize for my ignorance. I have only the vaguest idea of the distinctions between compilation, linking, assembly, and packaging.
What I was trying to say in my earlier response is that I suspect that my question about Agora might be a red herring, and that my problem lies in my gcc installation, or libmemcached, or something. I suspect that because when I run gcc test.c on
#include <stdio.h>
#include <libmemcached/memcached.h>
int main() {
printf("Hello, World!");
}
I get the same error that I’m getting from Agora, but in this case Agora is totally uninvolved.
NixOS’s environment.systemPackages is not meant to be picked up by build systems. Typical approaches for “development environments” are:
nix-shell -p memcached libmemcached
(and do the build inside that shell) That’s the “quickest approach”. For more complex stuff you may want to
create a shell.nix in the project’s directory instead of supplying the parameters.
That also allows a bit more customization and it’s more similar to actually packaging the build for NixPkgs.
Either (interactive) invocation may be “improved” by --pure, depending on what you like. It’s also possible to
create a non-interactive build/package, basically as-if to be submitted to github.com/nixos/nixpkgs . Those can again get improved isolation by configuring with enabled sandboxing; on Linux or even NixOS there’s probably very little down-side in having it on.