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