Hi Austin, 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.
Edward, I'll do that, thanks! Cheers Luke On Sat, Sep 14, 2013 at 12:50 AM, Austin Seipp <aus...@well-typed.com>wrote: > 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 <ezy...@mit.edu> wrote: > > 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/ >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs