Re: location of libraries etc
On Tue, Nov 06, 2001 at 08:44:30PM +0100, Robert Bihlmeyer wrote:
> Michael Banck <mbanck@gmx.net> writes:
>
> > The package features quite some libraries, I split them up
> > into two logical parts, but I'm hesitant where to put them, ie. under
> > /usr/lib or some directory /usr/lib/mpqc for example.
>
> Just for clarification -- we're talking about _shared_ libraries, right?
Yes. Well, both shared and static. I thought they were normally in the
same directory. sc-config below is about the development/static part
though, I mixed that up a bit, sorry.
> > The problem is with the names, they look quit common, e.g. libcontainer,
> > libmisc, libref, liboptions...
>
> Ugh. While I can't find libraries of with these names already in
> Debian, sooner or later, someone will have the same stupid idea of
> naming her library "liboptions". (IIRC some BSDs actually have a
> standard libmisc.)
Well, they rely on the user/admin installing their stuff below a
'target-directory' and tune ld.so.conf. It took quite some time to get
them into a FHS-compliant state although they're using autotools.
> > 1. Convince upstream to rename them. Yuck, I haven't even contacted them
> > about this, they follow some strange file-hierachy-policies anyway, but
> > I could try.
>
> Best. May be hard.
OK, I'll ask them. I need to convince them that searching for 'elements.txt'
in $(SCLIB_DIR) hardcoded isn't really the right thing to do anyway.
> > Would the 'sc-config' program be sufficient or would I have to change
> > /etc/ld.so.conf (something I'd like to avoid)?
> ld.so.conf, yes, or binaries won't find your library in
> /usr/lib/<mumble>/.
Yep. Logical error on my part confusing normal and development packages.
> An alternative is to wrap all binaries in scripts
> that set LD_LIBRARY_PATH accordingly. -rpath is another one, but
> outlawed in Debian.
Well, the run-time stuff from the package knows about where the
libraries got installed from ./configure I think. The other application
I know that uses MPQC has to be ported to the current version first to
find out. But still, I think changing ld.so.conf is the most reasonable
thing to do until upstream changes the names.
> > Dropping the headers directly under /usr/include would just result in
> > three directories: math, utils and chemistry, which wouldn't be very
> > beautiful either.
>
> Exactly. Put them in a subdirectory, teaching dependent programs to
> find the right location for include files is easier than for shared
> libs.
OK.
> > Oh, and another thing: dpkg-genchanges (I think) complains that the
> > source packages doesn't have a Section:. Is this a problem?
> Section is mandatory, see policy appendix C.2.2. It is not clear to me
> why -- users are never presented with the section of a source package.
Thanks, I fixed this by setting source section to science. That's where
the whole beast comes from at least.
thanks a lot,
Michael
Reply to: