Re: Fwd: Re: [MoM] ampl-netlib-solvers
Hi Andrei,
On Thu, Sep 24, 2020 at 11:31:56AM +0200, Andrei Rozanski wrote:
> Thanks for the answer.
You are welcome. :-)
> On 9/24/20 10:06 AM, Andreas Tille wrote:
> > The thing is that I was wondering why while the symlink is set inside
> > the resulting tarball the actual *.a lib was missing. The answer was
> > simple - the sequence in the debian/*links file was wrong.
> >
> Ok. I have removed the .links file and changed d/rules. (commit
> fb3ed2f5b9a313134a7abbffe23159b8f6fb4eb6)
Please always try to build before commiting. The build fails with
dh_install
mv usr/lib/x86_64-linux-gnu/amplsolver.a usr/lib/x86_64-linux-gnu/libamplsolver.a
mv: cannot stat 'usr/lib/x86_64-linux-gnu/amplsolver.a': No such file or directory
due to the fact that the source file you want to move can be actually
found in
debian/`dh_listpackages`/usr/lib/${DEB_HOST_MULTIARCH}/amplsolver.a
where it was moved before. ;-)
BTW, there are multiple ways to approach the renaming. Alternatively you
can also do
mv sys.*/amplsolver.a sys.*/libamplsolver.a
**before** dh_install. (See below why I'm writing sys.* !)
You could also patch a makefile (I really hate such self-invented
configure scripts - sometimes it is less work to simply add autoconf or
cmake code (depending from your preference for a build system) to create
a proper library name. See also in the end of this mail.
Please also note that Debian builds on several hardware architecture and
operating systems (also bsd and hurd). Since debian/*.install has
sys.x86_64.Linux/
this will fail on all other build architectures than amd64 under Linux.
May be its sensible to replace it simply by
sys.*/
The package is finaly a library. I admit I would not have started
with the suggested package in the first place if I would have realised
this. However, its possibly not a bad example to learn step by step.
In Debian it is mandatory to provide a shared library - extra points if
a static library is provided in *addition*. So we do not only need to
adapt the binary package name but also we need to provide two binary
packages - one with the shared library and one with the header files +
optional static library. May be you want to have a look into
libsmithwaterman[1] which is an simply example for a library (feel free
to ignore the additional third binary package smithwaterman which just
provided a tool that uses the library).
Its a simple package also featuring a rewrite of the build system
(which might or might not be appropriate here - just mentioning it)
and shows the two binary packages what files belong where. (For
the moment feel free to ignore d-shlibs - I'll explain later if needed.
It works only if shared *and* static library are provided.)
Please do not hesitate to ask if something is not clear.
Kind regards
Andreas.
[1] https://salsa.debian.org/med-team/libsmithwaterman
--
http://fam-tille.de
Reply to: