From: Bruno Haible <bruno@clisp.org>
To: bug-gnulib@gnu.org
Cc: Szabolcs Nagy <Szabolcs.Nagy@arm.com>, nd <nd@arm.com>
Subject: Re: how to build gnulib for shared libraries?
Date: Thu, 20 Dec 2018 04:18:52 +0100 [thread overview]
Message-ID: <5521798.mbTqcbUqQy@omega> (raw)
In-Reply-To: <1e18747f-bdb2-325f-f686-64551392f7d4@arm.com>
Hi Szabolcs,
(or should I say "Hi Nagy"? Sorry, with Hungarian proper names, I never
know what is the surname and what is the given name.)
> by default gnulib is not built with -fPIC so it is not
> suitable for shared libraries.
>
> is there an easy way to build gnulib .a with -fPIC so
> it can be used with shared libraries and executables as
> well within the same project?
The easy way is to use libtool, in combination with the technique
described in
https://www.gnu.org/software/gnulib/manual/html_node/Modified-build-rules.html .
You find an example here:
https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=blob;f=gettext-tools/gnulib-lib/Makefile.am
For shared libraries that are private to your application, this is all
you need.
For shared libraries that are visible to other applications, you should
consider hiding the gnulib symbols. Since the set of gnulib symbols depends
on the platform, I usually follow the approach to export only a given set
of symbols (defined by .h files) and hide all the rest. Find an
example of this technique here:
https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=blob;f=gettext-tools/libgettextpo/Makefile.am
> only elf targets need to be supported so ideally all
> gnulib replacement symbols should have hidden visibility
If all your targets support __attribute__((__visibility__("hidden"))),
you can use the option determined by gnulib module 'lib-symbol-visibility'.
Documentation:
https://www.gnu.org/software/gnulib/manual/html_node/Exported-Symbols-of-Shared-Libraries.html
Otherwise the only reliable way to hide symbols is by adding #define
instructions through config.h.
> object files should be built only once (with -fPIC)
Try 'configure --disable-static --enable-shared'.
> nor libtool dependency.
libtool is part of the GNU build system. If you don't want libtool,
you're on your own. You'll have different build rules for every platform,
essentially. It can be done (look at libncurses, for example), though.
Bruno
next prev parent reply other threads:[~2018-12-20 3:19 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-14 12:18 how to build gnulib for shared libraries? Szabolcs Nagy
2018-12-20 3:18 ` Bruno Haible [this message]
2019-01-03 15:58 ` Szabolcs Nagy
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
List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5521798.mbTqcbUqQy@omega \
--to=bruno@clisp.org \
--cc=Szabolcs.Nagy@arm.com \
--cc=bug-gnulib@gnu.org \
--cc=nd@arm.com \
/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).