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 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 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/