<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'll start looking into it.</div><div><br></div><div>Edward, I'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"><<a href="mailto:austin@well-typed.com" target="_blank">austin@well-typed.com</a>></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'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 'if os(windows)' block. Fixing the remaining ones is probably<br>
also pretty simple, but a little more refactoring: you'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're<br>
using Stage1Only, as to whether to include them (someone pipe up here<br>
if I'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'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 'libtool' 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 <<a href="mailto:ezyang@mit.edu">ezyang@mit.edu</a>> wrote:<br>
> Hey Luke,<br>
><br>
> Please file a bug. Add static001 as a failing test case which is<br>
> producing these errors.<br>
><br>
> Thanks,<br>
> Edward<br>
><br>
> Excerpts from Luke Iannini's message of Thu Sep 05 18:40:14 -0700 2013:<br>
>> Hi all,<br>
>><br>
>> I'm trying to track down the last warnings in GHC iOS.<br>
>><br>
>> We get this waterfall of warnings like:<br>
>> warning same member name (Types.o) in output file used for input files:<br>
>> /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>
>> and:<br>
>> /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>
>> due to use of basename, truncation and blank padding<br>
>><br>
>> and<br>
>><br>
>> file:<br>
>> /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>
>> has no symbols<br>
>><br>
>> when we run libtool to create the static libraries, and I was wondering if<br>
>> anyone had any ideas what causes them so I could start debugging... I can't<br>
>> seem to find much information about the warning.<br>
>><br>
>> Here's the output of<br>
>> i386-apple-darwin11-ghc -staticlib test.'s<br>
>> where test.hs is simply: main = print "hello world"<br>
>> <a href="https://gist.github.com/lukexi/25bfb42616933b0f1542" target="_blank">https://gist.github.com/lukexi/25bfb42616933b0f1542</a><br>
>> and here's the same with -v3<br>
>> <a href="https://gist.github.com/lukexi/c1fbbe32cef9e3965a72" target="_blank">https://gist.github.com/lukexi/c1fbbe32cef9e3965a72</a><br>
>><br>
>> I suppose I can simply suppress the output of libtool when we call it from<br>
>> GHC, but I'd love to find the root cause if we can.<br>
>><br>
>> Thanks for any hints!<br>
>> Cheers<br>
>> Luke<br>
</div></div>> _______________________________________________<br>
> ghc-devs mailing list<br>
> <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
> <a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
><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>