Wed Oct 30 06:20:16 EDT 2019

Producing a properly linked toolchain

I want to limit the effects of the temporary FHS that is used to build
a buildroot sdk, such that the sdk can also be used outside.

This really should work.  Let's give it a try in a toy problem.

EDIT: Too much of a toy problem.

EDIT: Makde a libusb1.0 toy problem that doesn't have paths set
correctly after nix-build

tom@panda:~/exo/nix/fhs$ ldd /nix/store/darkwrwklf1f50lnyqa7nj5nh3bn99f2-run-inner/bin/test 
	linux-vdso.so.1 (0x00007ffee85d7000)
	libusb-1.0.so.0 => /lib/x86_64-linux-gnu/libusb-1.0.so.0 (0x00007fc3107cd000)
	libc.so.6 => /nix/store/681354n3k44r8z90m35hm8945vsp95h1-glibc-2.27/lib/libc.so.6 (0x00007fc310a38000)
	libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007fc310a17000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fc3105b0000)
	/nix/store/681354n3k44r8z90m35hm8945vsp95h1-glibc-2.27/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fc3109e6000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fc3103a8000)

I need to know how this is usually done.  I.e. create the same
example, but do it the nix way.

So here are some ideas:

- To produce a buildroot toolchain, something needs to happen still.
  Either use wrappers that keep the FHS this was built in, or properly
  fix each binary.  The wrappers seem to be a better idea.

- It is not a problem for cross compilation targets of course.

The question is then: how does nix fix up link paths.
Look at the wrapper maybe?

which gcc

That doesn't make me much wiser without already knowing some background.

I think I understand what the idea is (patchs are patched), but I
don't see where it is happening.