On 28/08/15 16:48, Robert Millan wrote:
El 25/08/15 a les 23:16, Antti Kantee ha escrit:
So? For example, rumpdev_pci doesn't link against rumpdev (why else
are you specifying -lrumpdev or -lrump for that matter?).
Same reason. Except here it isn't a problem because I can just add them
unconditionally when building the end user of librumpdev_pci.
If Hurd cares only about shared libraries, go ahead, your proposal has
no downsides. I'm just saying that things will break for static
linking unless you carry the dependency chain over to the executable
link phase.
Okay, I see your point now. I admit to being a bit careless about static
linking, but this is just my bias (not a Hurd thing AFAIK).
So how does the end user of librumpdev_pci know whether additional
libraries (e.g. -lpciaccess) are needed on this platform?
I don't know. Usually, though, end users don't know very much (nor do I
advocate that they should). Makefiles know at least something. In the
odd case that Hurd isn't one of the supported platforms for whatever
application/service/server (which I'd find odd considering the case),
I'm sure Hurd users are expert enough to figure out a missing libpciaccess.
Anyway, like I said earlier, if you think it's better to link against
libpciaccess for shared libs, please go right ahead. I was just trying
to find a systematic error in how rump kernel components are produced,
and based on this discussion I couldn't find one.
Maybe it should be using pkg-config then?
No strong feelings this way or that way. Go ahead if you think it suits
your use case.
