From: Mark Wielaard <mark@klomp.org>
To: "Dmitry V. Levin" <ldv@altlinux.org>
Cc: elfutils-devel@sourceware.org
Subject: Re: [PATCH] Drop $(EXEEXT) suffix from shared libraries
Date: Wed, 09 Dec 2020 23:42:44 +0100 [thread overview]
Message-ID: <82db3b905383312bddafba7f93da15946214a23b.camel@klomp.org> (raw)
In-Reply-To: <20201209222009.GA18964@altlinux.org>
Hi Dmitry,
On Thu, 2020-12-10 at 01:20 +0300, Dmitry V. Levin wrote:
> OK, there was no mystery at all:
>
> $ git grep '_PROGRAMS.*_LIBRARIES'
> libasm/Makefile.am:noinst_PROGRAMS = $(noinst_LIBRARIES:_pic.a=.so)
> libdw/Makefile.am:noinst_PROGRAMS = $(noinst_LIBRARIES:_pic.a=.so)
> libelf/Makefile.am:noinst_PROGRAMS = $(noinst_LIBRARIES:_pic.a=.so)
>
> In other words, automake was told that libasm.so, libdw.so, and libelf.so
> are noinst_PROGRAMS, and rightfully decided that they shall have $(EXEEXT)
> suffix.
>
> What was the reason for including these libraries into noinst_PROGRAMS?
Unfortunately our version control only goes back 15 years and this
particular change was from before that. I think they are noinst because
they have explicit install rules. But it probably should have been
noinst_DATA instead. The old backends libraries (when we would still
create and install that before commit 4f937e24d) used noinst_DATA
instead.
But using noinst_DATA instead gives the following warnings:
libasm/Makefile.am:66: warning: variable 'libasm_so_SOURCES' is defined but no program or
libasm/Makefile.am:66: library has 'libasm_so' as canonical name (possible typo)
libdw/Makefile.am:114: warning: variable 'libdw_so_SOURCES' is defined but no program or
libdw/Makefile.am:114: library has 'libdw_so' as canonical name (possible typo)
libelf/Makefile.am:116: warning: variable 'libelf_so_SOURCES' is defined but no program or
libelf/Makefile.am:116: library has 'libelf_so' as canonical name (possible typo)
And just adding them to noinst_LIBRARIES says:
libasm/Makefile.am:37: error: 'libasm.so' is not a standard library name
libasm/Makefile.am:37: did you mean 'libasm.a'?
libdw/Makefile.am:38: error: 'libdw.so' is not a standard library name
libdw/Makefile.am:38: did you mean 'libdw.a'?
libelf/Makefile.am:38: error: 'libelf.so' is not a standard library name
libelf/Makefile.am:38: did you mean 'libelf.a'?
Hohum. I don't know what the correct hack/tweak is in this case.
Cheers,
Mark
next prev parent reply other threads:[~2020-12-09 22:42 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-30 8:00 Dmitry V. Levin
2020-11-30 20:35 ` Mark Wielaard
2020-12-06 11:49 ` Mark Wielaard
2020-12-09 19:55 ` Mark Wielaard
2020-12-09 22:04 ` Dmitry V. Levin
2020-12-09 22:20 ` Dmitry V. Levin
2020-12-09 22:42 ` Mark Wielaard [this message]
2020-12-09 23:09 ` Dmitry V. Levin
2020-12-09 23:34 ` [PATCH] Fix automake warnings Dmitry V. Levin
2020-12-10 10:09 ` Mark Wielaard
2020-12-10 10:30 ` Dmitry V. Levin
2020-12-10 11:28 ` Mark Wielaard
2020-12-10 11:52 ` Dmitry V. Levin
2020-12-10 11:57 ` Mark Wielaard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=82db3b905383312bddafba7f93da15946214a23b.camel@klomp.org \
--to=mark@klomp.org \
--cc=elfutils-devel@sourceware.org \
--cc=ldv@altlinux.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).