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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
