<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 29, 2015 at 11:44 AM, Rick Troth <span dir="ltr"><<a href="mailto:rmt@casita.net" target="_blank">rmt@casita.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">I was surprised that one build w/o -fPIC appeared to be bigger in
size then the same build with -fPIC. Would expect PIC support to
increase the size, not shrink it. (Or maybe I was cross-eyed.) Did
not compare performance of the two. <br></div></blockquote><div><br></div><div>I'm no sure where the -fPIC came in (presumably in a library that was used by the dependent?), but if it was part of a larger "statically link everything I need to run" vs "make this use shared objects", I can see the former resulting in a larger dependent.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class="">
<blockquote type="cite">
<pre>As to knowing if -fPIC is needed -- that's not known
until you try to build the dependent, right?</pre>
</blockquote>
<br></span>
Sure, but autoconf/automake discovers things like that by trying a
number of small compiles.<br><br></div></blockquote><div><br></div><div>I guess I'm not remembering autoconf/automake (or, rather, a dependent package's autoconf output) automatically pulling in or figuring out dependencies on other packages and then actually building those packages (other than having them say "Hey, you don't have package X; go get/make it!"). If it's going that deep, then, yeah, there should have been an explicit addition to ensure that the dependencies are built using the proper flags. But doing that seems kind of dangerous -- I mean, what if some other (previously installed) dependent requires a particular compilation/environment and then the build of the latest dependent goes in and automatically changes things on its own to suit the latest dependent's (incompatible) needs?</div><div><br></div><div>Or are you saying that for a given package, the build blows up because said package's configure didn't bother to set up the right compilation flags for said package? </div></div><br><br></div></div>