From owner-freebsd-arch Tue Mar 13 15:28:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 83CCF37B718 for ; Tue, 13 Mar 2001 15:28:41 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id QAA90969 for arch@FreeBSD.org; Tue, 13 Mar 2001 16:28:40 -0700 (MST) (envelope-from ken) Date: Tue, 13 Mar 2001 16:28:40 -0700 From: "Kenneth D. Merry" To: arch@FreeBSD.org Subject: sbufs in userland, proposed solution Message-ID: <20010313162840.A90872@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Well, the way I'm planning on going with putting sbufs in userland is to create a new library, libsbuf. libcam will be complied with a dependency on libsbuf, so libsbuf will automatically get pulled in for applications that dynamically link with libcam. Since most all the ports that use libcam that I know about (xmcd, tosha, cdrecord, cdda2wav, SANE) link dynamically, they should continue to work without recompilation. (The same would be true with preexisting static binaries.) They will also work without source patches when recompiled. I will probably go ahead and send patches to the various authors to add libsbuf to the link line if it exists, just in case they decide to link statically at some point. As for applications that link statically (e.g. camcontrol), they'll have to add libsbuf to the link line in order to compile. There is apparantly no way around the static link problem, so this is something that has to be done, unless I go with one of the other two alternatives -- putting sbufs in libc or in libcam. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message