<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 06/29/2015 12:54 PM, Jeff Frontz
wrote:<br>
</div>
<blockquote
cite="mid:CAGvwsD=rOYo+L8CAcQNGOXMkxSid4AAz00CBDKwdAHEyxXeyKg@mail.gmail.com"
type="cite">
<pre wrap="">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.</pre>
</blockquote>
<br>
The package-of-interest has a couple of pre-req libraries that were
missing. As is my habit, I built them myself. I configured them with
"<font face="Courier New, Courier, monospace">--enable-static</font>"
so that the resulting executable (in the package) would not need
third-party shared libs when I push it out. <br>
<br>
Whether static or shared, the needed libraries shipped by the
distributor do not exhibit any problem when the package gets linked.
It's only the supporting libraries that I built manually that caused
linker errors. <br>
<br>
<br>
<blockquote
cite="mid:CAGvwsD=rOYo+L8CAcQNGOXMkxSid4AAz00CBDKwdAHEyxXeyKg@mail.gmail.com"
type="cite">
<pre wrap="">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?</pre>
</blockquote>
<br>
Sometimes automake/autoconf (by way of the usual '<font
face="Courier New, Courier, monospace">configure</font>' script)
will error out if a pre-req is missing. Other times, you get past
configuration and find out during compile (because a header is
missing) or during link (because the library is missing). Either
way, it's no big deal: you can install what is needed (from the
distro) or you can build it from source. Works. <br>
<br>
Most of the discovery during '<font face="Courier New, Courier,
monospace">./configure</font>' is things like "compile with
such-and-such flag" for dozens and dozens of such-and-such. The
focus is more of creating a viable Makefile. <br>
<br>
<br>
<blockquote
cite="mid:CAGvwsD=rOYo+L8CAcQNGOXMkxSid4AAz00CBDKwdAHEyxXeyKg@mail.gmail.com"
type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<br>
Exactly. <br>
Configure didn't figure out that "-fPIC" would be needed. As you
hinted earlier, might not be needed for "<font face="Courier New,
Courier, monospace">--enable-shared</font>". (So maybe that's why
'configure' doesn't check if "-fPIC" is needed?) But I built the
supporting libraries with "<font face="Courier New, Courier,
monospace">--enable-static</font>" in order that the shipped
executable would actually run w/o having to drag in co-reqs when
delivering. <br>
<br>
If anyone wants to devolve into a static versus shared discussion,
please change the subject line. <br>
<br>
Fun discussion so far. Thanks Jeff! <br>
<br>
-- R; <><<br>
<br>
<br>
<br>
</body>
</html>