pciutils-dev possibly somewhat broken in feisty?
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
pciutils (Ubuntu) |
Invalid
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: pciutils-dev
Although this specific case is not supported, there seems to be a greater underlying issue, here is what happens...
While trying to build the mactel macbook pro backlight control app I get the following error messages
--- snip ---
mgalvin@
gcc -Wall -g -Wextra -DVERSION=\"0.1.1\" backlight.c -o backlight -lpci
/usr/lib/
(.text+0x538): undefined reference to `gzopen'
/usr/lib/
(.text+0x5d1): undefined reference to `gzgets'
/usr/lib/
(.text+0x6d6): undefined reference to `gzclose'
/usr/lib/
(.text+0x6f8): undefined reference to `gzeof'
/usr/lib/
(.text+0x795): undefined reference to `gzclose'
/usr/lib/
(.text+0xbdb): undefined reference to `gzopen'
/usr/lib/
(.text+0xd78): undefined reference to `gzerror'
/usr/lib/
(.text+0xd9b): undefined reference to `gzclose'
collect2: ld returned 1 exit status
make: *** [backlight] Error 1
--- snip ---
Some digging turned up this stack of debian bugs which seem to also apply to feisty since we are using the same version of pciutils. The list of debian bugs is at:
Trying to build the suspend package utility s2ram on Feisty 32-bit I also ran into this problem. Based on what other people had said I believed initially it was a bug in the pciutils package, and libpci in particular.
After considerable hacking about between the configure scripts and Makefiles of pciutils/libpci and suspend-0.5 I realised that the compiler/linker errors detailed above were a bug in the Makefile of suspend-0.5.
pciutils/libpci is installed to /usr/lib/libpci.a and is a static library. It in turn relies on the zlib static library /usr/lib/libz.a. In its configure script it correctly passes the linker parameter "-lz" which causes ld (the GNU linker) to link libpci against libz.
suspend-0.5's Makefile omits to pass the same "-lz" to the linker, although it does pass "-lpci" correctly. Adding "-lz" as an additional linker parameter, and using LD_FLAGS in the s2ram target rule, solves the problem:
LD_FLAGS= -L/usr/ local/lib
LD_FLAGS += -lz
s2ram: s2ram.c dmidecode.c whitelist.c radeontool.c $(S2RAMOBJ)
$(CC) $(CFLAGS) -g s2ram.c $(S2RAMOBJ) $(LD_FLAGS) -lpci -o s2ram
I'm guessing that compilation issues with other source packages are caused by this same error in their configure scripts and/or Makefile.