From: Steven J Long <slong@rathaus.eclipse.co.uk>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] .LIBPATTERNS harmful?
Date: Sun, 22 Apr 2012 05:44:11 +0100 [thread overview]
Message-ID: <jn023c$dfl$1@dough.gmane.org> (raw)
Hi,
I've been working with GNU make quite a lot recently, and I came across the
.LIBPATTERNS variable. This variable means that make expands all -lname
prerequisites via a library path search of /lib and /usr/lib *before* any
command sees it. (It searches local paths set in the makefile first, which
is useful for linking to built libs, though imo the build-system is better
off using -L parameters in LDFLAGS for those.)
You can read about it in 'info make' Section 4.5.6 (just hit / and type
LIBPATTERN<Enter> to find it.)
The default setting is active in make as installed, as it should be, which
you can verify with: make -p -f /dev/null|grep -F LIBPATTERN
I can find nothing overriding it in portage, which makes sense, since in
general one cannot know if the package in question uses gmake .LIBPATTERNS
to link to locally-built libs. However I can't help thinking of it as
harmful for a package manager, since a command like ld would be given a
parameter of say, /usr/lib/libfoo.so, not -lfoo, meaning LDFLAGS would be
irrelevant for its lookup.
My feeling is that build-systems reliant on the default gmake behaviour for
locally-built libs (ie not setting any -L params and also having to link
locally) would be rare, but it's just that: a gut-feeling with no data.
Preferably they'd be marked as such so that the package manager could deal
with that corner-case, while patches to supply local -L params could be
worked on, in advance of submission upstream.
I'd hope upstream would accept them, since it makes cross-development
easier. (One definitely does not want make expanding -lname to a library in
/lib or /usr/lib in that case, and it's better to error out if the library
can't be found than link to host libs.)
The reason I bring it up is because we have been discussing library linkage
issues wrt initramfs. I also seem to recall quite a few blog posts and
discussions of arbitrary linkage to libs in /usr. .LIBPATTERNS not being
empty would certainly explain that.
Regards,
Steve.
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
next reply other threads:[~2012-04-22 4:41 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-22 4:44 Steven J Long [this message]
2012-04-22 15:17 ` [gentoo-dev] .LIBPATTERNS harmful? Mike Frysinger
2012-04-22 22:13 ` [gentoo-dev] " Steven J Long
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='jn023c$dfl$1@dough.gmane.org' \
--to=slong@rathaus.eclipse.co.uk \
--cc=gentoo-dev@lists.gentoo.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