On 30/10/15 11:40, Vincent Schwarzer wrote:
I was asking since you also ship with libraries like pthread which is build during the rump-build process. But I have still open points how to approach this (in general):- Libraries in a separate folder since it is a package and provide instructions about how to compile / link it? - Other approach would be to copy the library and header files into the appopriate rumprun folders. Still have to look in which folders the library would be necessary E.g. (Xen): ./rumprun/rumprun-x86_64/lib/rumprun-xen/libpthread.a ./rumprun/rumprun-x86_64/lib/libpthread.a ./obj-amd64-xen/buildrump.sh/lib/libpthread/libpthread.a ./obj-amd64-xen/dest.stage/rumprun-x86_64/lib/rumprun-xen/libpthread.a ./obj-amd64-xen/dest.stage/rumprun-x86_64/lib/libpthread.a Advantage: User could compile OpenMP programs by using -lgomp and save themself the Include and Link dance with the gcc which is quite picky when it comes to the order of the arguments (as seen before). I currently favor the second approach for the convenience of use but also don't have a overview over the whole rumpkernel eco system / vision.
First of all, you should not look into objdir, it's just for build-time stuff. Everything of relevance is now installed into destdir (./rumprun by default, but you can control it using -d to build-rr).
Second, libpthread is a poor example, since it's both a "user" library and a "system" library. What that means is that applications may link against it explicitly ("user"), but also that rumprun internally uses pthreads ("system") (*). If you look closely, you'll see one is a symbolic link to the other. Same goes for libc.
*) I would have rather have not used pthreads and instead have used bmk threads to create application main threads, but that requires the thread calling main() to be initialized as a pthread mainthread, and libpthread wasn't (understandably) too happy about >1 main thread. duh. So it was either going poking into libpthread internals or use pthreads.
Now, package libraries are not currently installed into the same destdir as the Rumprun base. That's probably because the package "infrastructure" predates the Rumprun destdir. It might make sense to install libs built by packages into the same destdir, but I would rather see that happen either for all packages or none, and making that decision will require additional discussion and meditation. The worst kind of software project is one where every little thing has its own way of reinventing all wheels (especially the steering wheel). So, for now, just look at how other packages install libraries and do the same.
Specifically, for your point about avoiding the link dance, I don't see how that follows. If the lib is in a regular search directory, you use -lgomp. If not, you use -L/path/to/libgomp -lgomp.
