<div dir="ltr">Hi Austin,<div><br></div><div>Awesome, thanks so much — that gives me a much better understanding and a good roadmap of how to fix it. I&#39;ll start looking into it.</div><div><br></div><div>Edward, I&#39;ll do that, thanks!</div>

<div><br></div><div>Cheers</div><div>Luke</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Sep 14, 2013 at 12:50 AM, Austin Seipp <span dir="ltr">&lt;<a href="mailto:austin@well-typed.com" target="_blank">austin@well-typed.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The second results are self explanatory: in your build, a lot of those<br>
object files are simply empty on your target. consUtils.o for example<br>
only has symbols defined on Windows - ditto with Win32Utils.c. But<br>
they are unconditionally included in the c-sources field of base, so<br>
it&#39;ll throw empty object files in, no questions asked. These two<br>
instances can probably be fixed by just moving the c-sources clause<br>
under an &#39;if os(windows)&#39; block. Fixing the remaining ones is probably<br>
also pretty simple, but a little more refactoring: you&#39;ll need to<br>
tweak rts/<a href="http://ghc.mk" target="_blank">ghc.mk</a> in order to not build those files, as part of<br>
`rts_C_SRCS`. It is probably OK to just discriminate on whether we&#39;re<br>
using Stage1Only, as to whether to include them (someone pipe up here<br>
if I&#39;m wrong.)<br>
<br>
The first one is more problematic to fix. Imagine I have an iOS<br>
application, which is actually an app.a file. My application depends<br>
on libA.a and libB.a - two separate libraries. libB is also a user of<br>
libA.<br>
<br>
I link against -lA and -lB at compile time, and get this warning. Why?<br>
Because app.a and libB.a *both* depend on libA.a. This confuses<br>
libtool obviously (and in certain situations is very bad.) Of course<br>
your situation is more confusing at a glance, because the two<br>
libraries are the same!<br>
<br>
What this is telling me is that somehow, libtool is trying to pick up<br>
two copies of base and shove them into the final file, and the symbol<br>
names obviously conflict. But it&#39;s not clear to me why this is the<br>
case.<br>
<br>
Perhaps try running with -keep-tmp-files and -v3, and after the<br>
compile finishes, invoke &#39;libtool&#39; with the -v flag to get some more<br>
verbose information?<br>
<div><div class="h5"><br>
<br>
<br>
On Sat, Sep 14, 2013 at 2:12 AM, Edward Z. Yang &lt;<a href="mailto:ezyang@mit.edu">ezyang@mit.edu</a>&gt; wrote:<br>
&gt; Hey Luke,<br>
&gt;<br>
&gt; Please file a bug.  Add static001 as a failing test case which is<br>
&gt; producing these errors.<br>
&gt;<br>
&gt; Thanks,<br>
&gt; Edward<br>
&gt;<br>
&gt; Excerpts from Luke Iannini&#39;s message of Thu Sep 05 18:40:14 -0700 2013:<br>
&gt;&gt; Hi all,<br>
&gt;&gt;<br>
&gt;&gt; I&#39;m trying to track down the last warnings in GHC iOS.<br>
&gt;&gt;<br>
&gt;&gt; We get this waterfall of warnings like:<br>
&gt;&gt; warning same member name (Types.o) in output file used for input files:<br>
&gt;&gt; /usr/local/ghc-ios-sim/lib/i386-apple-darwin11-ghc-7.7.20130828/base-4.7.0.0/libHSbase-4.7.0.0.a(Types.o)<br>
&gt;&gt; and:<br>
&gt;&gt; /usr/local/ghc-ios-sim/lib/i386-apple-darwin11-ghc-7.7.20130828/base-4.7.0.0/libHSbase-4.7.0.0.a(Types.o)<br>
&gt;&gt; due to use of basename, truncation and blank padding<br>
&gt;&gt;<br>
&gt;&gt; and<br>
&gt;&gt;<br>
&gt;&gt; file:<br>
&gt;&gt; /usr/local/ghc-ios-sim/lib/i386-apple-darwin11-ghc-7.7.20130828/base-4.7.0.0/libHSbase-4.7.0.0.a(consUtils.o)<br>
&gt;&gt; has no symbols<br>
&gt;&gt;<br>
&gt;&gt; when we run libtool to create the static libraries, and I was wondering if<br>
&gt;&gt; anyone had any ideas what causes them so I could start debugging... I can&#39;t<br>
&gt;&gt; seem to find much information about the warning.<br>
&gt;&gt;<br>
&gt;&gt; Here&#39;s the output of<br>
&gt;&gt; i386-apple-darwin11-ghc -staticlib test.&#39;s<br>
&gt;&gt; where test.hs is simply: main = print &quot;hello world&quot;<br>
&gt;&gt; <a href="https://gist.github.com/lukexi/25bfb42616933b0f1542" target="_blank">https://gist.github.com/lukexi/25bfb42616933b0f1542</a><br>
&gt;&gt; and here&#39;s the same with -v3<br>
&gt;&gt; <a href="https://gist.github.com/lukexi/c1fbbe32cef9e3965a72" target="_blank">https://gist.github.com/lukexi/c1fbbe32cef9e3965a72</a><br>
&gt;&gt;<br>
&gt;&gt; I suppose I can simply suppress the output of libtool when we call it from<br>
&gt;&gt; GHC, but I&#39;d love to find the root cause if we can.<br>
&gt;&gt;<br>
&gt;&gt; Thanks for any hints!<br>
&gt;&gt; Cheers<br>
&gt;&gt; Luke<br>
</div></div>&gt; _______________________________________________<br>
&gt; ghc-devs mailing list<br>
&gt; <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
&gt; <a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
&gt;<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
--<br>
Austin Seipp, Haskell Consultant<br>
Well-Typed LLP, <a href="http://www.well-typed.com/" target="_blank">http://www.well-typed.com/</a><br>
</font></span></blockquote></div><br></div>