> > 1) We want to minimize the number of external dependencies > required to > > use the software, so that installing it requires a minimum of fuss. > > You could provide an additional binary package containing the > needed libraries. Extremely easy ;)
I'd like to avoid packaging other projects' software if possible. It seems to cause confusion. > > > 2) I'm producing Debian packages for the software, so I > need to know > > which dynamic libraries my program will need when it is > executed. For > > example, if my program has been linked to libFLTK.so, then > my Debian > > package must state a package-dependency on the libfltk1.1 package. > > But if my program has been linked to libFLTK.a, no such package > > dependency exists and therefore my own Debian package > shouldn't list libfltk1.1 as a dependency. > > Debian packages provide both .a and .so files but GNU ld will > prefer the .so file. A package "libfoo" will typically provide something like "libfoo.so.1.3" and a symlink "libfoo.so.1". The package "libfoo-dev" will provide "libfoo.a", and a symlink "libfoo.so" which points at "libfoo.so.1". Thanks for the tip about GNU ld. > > > Because the computer that's being used to create the Debian > packages > > might have both libFLTK.a and libFLTK.so installed on it, I need to > > control, or at least know, which version of the FLTK > library was linked to my program. > > If you build on Debian, can't you use the dh_shlibdeps with a > proper debian/ directory? Thanks, this is very helpful. I didn't know about dh_shlibdeps. While I still don't have a good way to force my program to be linked against .a files rather than their .so counterparts, at least I know how to properly document the package dependencies now.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
