Package: liblockdev1-dev Version: 1.0.0 Severity: normal (Debian-mentors: this turns out to be a bug in liblockdev1-dev, it seems.)
It doesn't create the symlink that other shared-library -dev packages create; if I do the following, my problem (described in the quoted message below) goes away: /usr/lib# ln -s /lib/liblockdev.so.1 liblockdev.so Please let me know if I've misconstrued the problem. THanks. -- System Information Debian Release: testing/unstable Architecture: i386 Kernel: Linux zona 2.4.1 #1 SMP Mon Feb 12 21:30:11 EST 2001 i686 Versions of packages liblockdev1-dev depends on: ii libc6-dev 2.2.2-1 GNU C Library: Development Librari ii liblockdev1 1.0.0 Run-time shared library (libc6) fo David Coe <[EMAIL PROTECTED]> writes: > Hi mentors, > > I recently adopted camediaplay, which uses non-FHS lock files for > serial devices; I decided to do it right by installing liblockdev1 and > liblockdev1-dev and patching the source to use them. > > It works fine, but the liblockdev1 functions get linked statically to > camediaplay, rather than dynamically (shared), and I don't know how to > change the gcc invocations (or something else) to force it to use the > shared library. > > After reading the gcc howto, and some experimenting, I discovered that > if I move /usr/lib/liblockdev1.a out of the way, the functions get > linked shared (unresolved) as desired, but that's certainly not the > correct way to force it to do what I want. > > What am I doing wrong? Thanks. > > ... > make[1]: Entering directory > `/var/home/david/debian-packages/camediaplay/camediaplay-20010211/build' > cc -c -O -I. -I./../include -DHAVE_LIBLOCKDEV -c ./../src/main.c > cc -c -O -I. -I./../include -DHAVE_LIBLOCKDEV -c ./../src/uucplock.c > cc -o camediaplay main.o uucplock.o -llockdev > make[1]: Leaving directory > `/var/home/david/debian-packages/camediaplay/camediaplay-20010211/build' > touch build-stamp
