From: alexmcwhirter@triadic.us
To: gentoo-sparc@lists.gentoo.org
Cc: Jack Morgan <jmorgan@gentoo.org>
Subject: [gentoo-sparc] -fPIC vs -fpic = Headaches
Date: Sun, 04 Sep 2016 15:27:49 -0400 [thread overview]
Message-ID: <716202a344d702e496c97ecf840173c5@triadic.us> (raw)
In-Reply-To: <a489c0c4-bfbb-1597-3e79-4f78d8f5800a@gentoo.org>
I've come across a fun little issue lately when building sparc64
livecd's...
Some shared libaries need -fPIC to compile (libpcap for example), that's
an easy fix. However, some libraries compile fine with -fpic (libkudzu
for example). The issues is that shared libraries compiled with -fpic
can cause issues later on depending on how they are included into a
dependent application. An example is is hwsetup, which is compiled with
-fPIC by default, but depends on libkudzu which is compiled with -fpic
by default. This causes hwsetup to fail during compilation. This only
seems to be a issue with sparc64 and not sparc, as sparc64 still has a
lot of the same register restrictions that sparc has but with a higher
memory footprint.
Im tempted to say that everything on sparc should be compiled with -fPIC
over -fpic. This is how Debian does it (i believe they do it for every
arch). The reason i say this is because there is no way to tell if a
-fpic shared library will be a problem down the line in another
application. Short of building the whole portage tree repeatedly.
Right now im just fixing them as i come across them, but i'd like to
know anyones thoughts on this issue.
prev parent reply other threads:[~2016-09-04 19:41 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-28 23:06 [gentoo-sparc] Official SPARC64 Port Alex McWhirter
2016-01-28 23:26 ` [gentoo-sparc] " Mike Frysinger
2016-01-28 23:37 ` Alex McWhirter
2016-01-28 23:46 ` Mike Frysinger
2016-01-30 0:28 ` [gentoo-sparc] " Alex McWhirter
2016-01-30 0:44 ` Mike Frysinger
2016-01-30 0:55 ` Alex McWhirter
2016-02-01 9:24 ` Alex McWhirter
2016-02-01 17:44 ` Mike Frysinger
2016-02-01 19:29 ` Alex McWhirter
2016-02-01 20:24 ` Mike Frysinger
2016-02-01 20:34 ` Alex McWhirter
2016-02-01 20:51 ` Mike Frysinger
2016-02-01 22:03 ` Alex McWhirter
2016-02-04 18:40 ` Alex McWhirter
2016-02-04 21:54 ` Mike Frysinger
2016-02-04 23:44 ` Alex McWhirter
2016-02-07 10:35 ` Alex McWhirter
2016-02-08 15:21 ` Mike Frysinger
2016-02-08 20:48 ` Alex McWhirter
2016-02-09 5:11 ` Alex McWhirter
2016-02-09 6:14 ` Mike Frysinger
2016-02-13 9:26 ` Alex McWhirter
2016-02-13 11:25 ` Mike Frysinger
2016-02-13 17:32 ` Alex McWhirter
2016-02-13 21:26 ` Alex McWhirter
2016-02-14 0:44 ` Mike Frysinger
2016-02-14 23:44 ` Alex McWhirter
2016-02-15 2:13 ` Mike Frysinger
2016-02-17 22:11 ` Alex McWhirter
2016-02-17 22:46 ` Mike Frysinger
2016-02-17 22:52 ` Alex McWhirter
2016-02-19 8:37 ` Alex McWhirter
2016-03-11 3:53 ` Alex McWhirter
2016-08-08 22:52 ` Jack Morgan
2016-08-09 5:14 ` alexmcwhirter
2016-08-10 18:45 ` Jack Morgan
2016-08-31 17:26 ` alexmcwhirter
2016-09-01 0:46 ` Jack Morgan
2016-09-04 19:27 ` alexmcwhirter [this message]
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=716202a344d702e496c97ecf840173c5@triadic.us \
--to=alexmcwhirter@triadic.us \
--cc=gentoo-sparc@lists.gentoo.org \
--cc=jmorgan@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