<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 10/5/16 3:28 PM, Brandon Allbery
wrote:<br>
</div>
<blockquote
cite="mid:CAKFCL4UyT3bsK=BarxG8NkJBEV0GMTf0zZx0V0webTn35MQoaw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Wed, Oct 5, 2016 at 6:21 PM, Mick
Jordan <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:mick.jordan@oracle.com" target="_blank">mick.jordan@oracle.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">I have
several libraries installed via MacPorts (that also exists
in /usr/lib FWIW), e.g, libpcre and libz. I was rather
surprised to see that these resolve to the MacPorts
location,i.e., /opt/local/lib even though I am not passing
-L/opt/local/lib to the link step. I thought this might be
because I was using gcc to do the compilation/linking and
that is also installed via MacPorts, but I get the same
behavior when using clang. I added -Wl,-v to the link step
and it lists the directories it is searching and
/opt/local/lib is not included in the list. So my question
is how is ld resolving to /opt/local/include. I have no
environment variables such as LDFLAGS set, although
/opt/local/bin is on my PATH.<br>
<br>
I'm running MacPorts 2.3.4 in El Capitan.<br>
</blockquote>
<div><br>
</div>
<div>How is the program being built? If it uses a build
framework such as autoconf or cmake, or even just
pkgconfig, it will often find things itself (and sometimes
there's no way to stop it from doing so).</div>
</div>
<div><br>
</div>
</div>
</div>
</blockquote>
Yes, the act of writing the email turned out to improve my
understanding of what is happening but, unfortunately, not before I
hot the send button. The libraries in question were actually
compiled by another framework where /opt/local/lib was being passed.
<br>
<br>
Thanks<br>
Mick<br>
<br>
</body>
</html>