On 25/08/15 21:01, Robert Millan wrote:
You still need to supply -lpciaccess "manually" if you want to link
a static rump kernel.
I'm not sure I follow. Please correct me if I missunderstood, but
what I see is that
the Makefile in libpci (buildrump.sh tree) is the one actually
building and linking of
OS-specific code in pci-userspace.
Therefore the Makefile in pci-userspace needs to pass along its
requirements by exporting
some variables.
Is that correct?
Shared libraries are linked when they are created, static libraries
are just archived. There is linking happening
in libpci in the latter case and hence LDFLAGS is not used.
Does the build of libpci on Hurd fail if you don't supply the
additional LDFLAGS?
No, but it needs symbols which aren't provided by any of its library
dependencies. E.g.
$ nm -D /usr/lib/librumpdev_pci.so.0.0 | grep pci_system_init
U pci_system_init
$ ldd /usr/lib/librumpdev_pci.so.0.0
libc.so.0.3 => /lib/i386-gnu/libc.so.0.3 (0x0105b000)
libmachuser.so.1 => /lib/i386-gnu/libmachuser.so.1 (0x0121a000)
/lib/ld.so.1 (0x00001000)
libhurduser.so.0.3 => /lib/i386-gnu/libhurduser.so.0.3
(0x01232000)
So? For example, rumpdev_pci doesn't link against rumpdev (why else are
you specifying -lrumpdev or -lrump for that matter?). Furthermore,
static libraries don't link against anything.
$ cat test.c
int
main()
{
}
$ gcc test.c -lrump -lrumpdev -lrumpdev_pci -lrumpvfs
/usr/lib/gcc/i586-gnu/4.9/../../../librumpdev_pci.so: undefined
reference to `pci_device_cfg_read_u32'
/usr/lib/gcc/i586-gnu/4.9/../../../librumpdev_pci.so: undefined
reference to `pci_device_cfg_write_u32'
/usr/lib/gcc/i586-gnu/4.9/../../../librumpdev_pci.so: undefined
reference to `pci_device_next'
/usr/lib/gcc/i586-gnu/4.9/../../../librumpdev_pci.so: undefined
reference to `pci_slot_match_iterator_create'
/usr/lib/gcc/i586-gnu/4.9/../../../librumpdev_pci.so: undefined
reference to `pci_system_init'
collect2: error: ld returned 1 exit status
$ gcc test.c -lrump -lrumpdev -lrumpdev_pci -lrumpvfs -lpciaccess
$
I find it strange that librumpdev_pci.so.0.0 build didn't break on the
unresolved symbol. Am I missing
something obvious?
You're missing that you're linking a shared library. (it's quite hard
to miss if you look closely ;)
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.
