On Thu, Apr 19, 2012 at 6:48 PM, Charlie Sharpsteen <span dir="ltr">&lt;<a href="mailto:chuck@sharpsteen.net">chuck@sharpsteen.net</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">On Thu, Apr 19, 2012 at 6:40 PM, Frank Warmerdam <span dir="ltr">&lt;<a href="mailto:warmerdam@pobox.com" target="_blank">warmerdam@pobox.com</a>&gt;</span> wrote:<br></div><div class="gmail_quote"><div class="im">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Charlie,<br>
<br>
The typical reason would be that adding opendap adds stuff into the<br>
libraries list that results in other &quot;test links&quot; failing.  It would<br>
be helpful if you could file a bug and attach the config.log.<br>
<br>
Best regards,<br>
Frank</blockquote><div><br></div></div><div>I looked through the config.log a little closer, and in all four cases the following argument was added to the compiler flags:</div><div><br></div><div>    -arch x86_64 i386 ppc</div>


<div><br></div><div>This is bad for two reasons:</div><div><br></div><div>  - I&#39;m not trying to build a universal binary and all of my components are x86_64 only.</div><div><br></div><div>  - `-arch x86_64 i386 ppc` isn&#39;t even a valid compiler flag. The proper thing to pass would be `-arch x86_64 -arch i386 -arch ppc`, so the compiler would error out even if I had the universal binaries to support a 3-way build.</div>


<div><br></div><div>I&#39;ve traced the offending flags to `dap-config` so it looks like this is an OpenDAP bug now, not a GDAL bug.</div><div><br></div><div>Apologies for the noise.</div><span class="HOEnZb"><font color="#888888"><div>

<br></div><div><br></div><div>
-Charlie </div></font></span></div>
</blockquote></div><br><div><br></div><div>A final followup on this situation for anyone else who is trying to build GDAL with libdap support on OS X.</div><div><br></div><div>The root cause of the problem came down to bad pkg-config files shipped with OS X 10.6 and 10.5. When libdap builds, information on curl is requested from `pkg-config` using the following:</div>

<div><br></div><div>    pkg-config --static --libs libcurl</div><div><br></div><div><br></div><div>On Snow Leopard, the default `libcurl.pc` file will return the following in answer to the above query:</div><div><br></div>

<div>    -Wl,-weak-lldap -dynamic -arch x86_64 i386 ppc -Os -pipe -g0 -Wno-system-headers -Wl,-search_paths_first -Wl,-weak-lgssapi_krb5 -Wl,-weak-lkrb5 -Wl,-weak-lk5crypto -Wl,-weak-lcom_err -Wl,-weak-lresolv -lcurl -lssl -lcrypto -lz</div>

<div><br></div><div><br></div><div>As you can see, this contains the string `-arch x86_64 i386 ppc` which is both troublesome (forces universal binary builds when you don&#39;t want them) and illegal (each architecture _must_ be proceeded by a new -arch flag). The flags returned by `pkg-config` are also stored in the `dap-config` script and from there they contamination spreads to other packages like GDAL. The `libcurl.pc` file shipped with OS X 10.7 is much more sane and does not suffer from these problems.</div>

<div><br></div><div><br></div><div>Solution:</div><div><br></div><div>When configuring libdap on Leopard or Snow Leopard, always pass &quot;--with-curl=/usr&quot; if you want to build against the system curl. Providing information on curl will cause the configure script to avoid querying pkg-config and receiving bad flags.</div>

<div><br></div><div><br></div><div>Hope this helps anyone else who runs into this problem!</div><div><br></div><div>-Charlie</div>