Re: -findirect-dispatch: broken on Linux, working on Mingw?

[Marco Trudel <mtrudel at gmx dot ch>]

Andrew Haley wrote:
> Marco Trudel writes:
>  > Andrew Haley wrote:
>  > > Marco Trudel writes:
>  > >  > Andrew Haley wrote:
>  > >  > > Marco Trudel writes:
>  > > 
>  > >  > >  > Is there a better way to solve this problem?
>  > >  > > 
>  > > 
>  > > Notice this fragment:
>  > > 
>  > > -lgcc -lgcj_bc -lm
>  > > 
>  > > shouldn't be there.  -lgcj_bc should only be linked when linking
>  > > dynamically.  It should be 
>  > > 
>  > > -lgcc -lgcj -lm
>  > 
>  > Well then, lets take your suggested line:
>  > *lib: %{static-libgcj:-non_shared -lgcj 
>  > -call_shared;:%{s-bc-abi:-lgcj_bc;:-lgcj}} -lm   -lpthread -lrt    -ldl 
>  > %(libgcc) %(liborig)
>  > and change it to:
>  > *lib: %{static-libgcj:-non_shared -lgcj 
>  > -call_shared;:%{s-bc-abi:-lgcj;:-lgcj}} -lm   -lpthread -lrt    -ldl 
>  > %(libgcc) %(liborig)
>
> My suggestion is
>
> *lib: -lgcj  -lm   -lpthread -lrt    -ldl %(libgcc) %(liborig)

Sorry, I wasn't sure if you meant this as suggestion or if you meant 
that I just should stay with the default. This prints "gcj: unrecognized 
option '-s-bc-abi'" as warning but otherwise works.


Marco


>  > That makes compiling the sample with indirect dispatch work (it also 
>  > runs correct). But I really have no idea what I'm doing... Maybe you 
>  > know more?
>
> You should only ever link statically with libgcj, not libgcj_bc.
> That's only for shared libraries.
>
>  > > I guess my fix doesn't work on Windows becasue you don't use the
>  > > static-libgcj command, so it assumes dynamic linking.  I suppose for a
>  > > staticonly build you really need
>  > > 
>  > > *lib: -lgcj  -lm   -lpthread -lrt    -ldl %(libgcc) %(liborig)
>  > 
>  > You mean the original line, right?
>
> I have no idea what you're talking about.  What original line?
>
>  > Well, your original fix doesn't work on Linux either.
>
> It works for me, as long as you compile with -static-libgcj.
>
>  > But with the changed one, it works too...
>
> OK.
>
> Andrew.