Build path leaking into various files shipped in the frida packages

[CyrilBrulebois]

Spotted while working on automating Frida builds for the 16.4.* series:

• Two files end up inside the package under the build path (e.g. /home/kibi/deb-frida/…), namely frida-core-1.0.deps and frida-core-1.0.vapi. Fixing the build system didn't seem easy so I went for a workaround: fixing location and one reference (from a .pc file) after dh_auto_install.
• A few files reference the build path. That was already the case with past versions.

This issue is about that second topic: it seems one Node package is used to bundle a lot of things together, optionally including a sourceRoot setting in there. It would be best to turn that off if at all possible, but it seems likely that we're only leaking the “we built this package under that directory” information (possibly making reproducible builds harder, but remember an SDK+toolchain download are already in the picture).

After a successful build, the list of files can be built this way:

$ grep $(pwd) -rl debian/frida
debian/frida/usr/lib/x86_64-linux-gnu/libfrida-core-1.0.a
debian/frida/usr/lib/python3/dist-packages/frida/_frida.abi3.so
debian/frida/usr/lib/python3/dist-packages/frida_tools/fs_agent.js
debian/frida/usr/lib/python3/dist-packages/frida_tools/itracer_agent.js

Amusingly, the static library and dynamic library (the Python module) embed the same kind of payload as can be seen in Javascript files…

[CyrilBrulebois]

That patch seems to do the trick for both JS files, as well as for the static library and the Python module.

@U039b: The question is whether to redo e.g. the whole 16.4.* series of builds with it, or if wait until after 16.4.8 has been tested/integrated as it is, and only do that for further builds? I've just verified the patch still applies cleanly to 16.4.8 and does its job there as well.