"has no symbols"/"same member name" warnings using libtool

[Luke Iannini]

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 <austin at 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 <ezyang at 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 at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
> >
>
>
>
> --
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130916/726a0dd7/attachment.htm>