This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcj, shared libraries, and -Bsymbolic


Bryce McKinlay writes:
 > Tom Tromey wrote:
 > 
 > >rth> What you actually want is (at least for -findirect-dispatch) is to 
 > >rth> not export any symbols whatsoever.  And to do so as simply as not
 > >rth> marking the symbols TREE_PUBLIC in the front end.
 > >
 > >Andrew> I know.  However, at present this breaks CNI.
 > >
 > >I was thinking about this yesterday and it occurred to me that CNI is
 > >already broken with BC.  So I think we could make this change now
 > >without making things worse... assuming we have the time to do it.
 > 
 > Certainly, making all Java symbols local is the best solution - but
 > IMO we must fix CNI before we can do that.
 > 
 > Although calls made from CNI arn't yet implemented in the "binary
 > compatible" way, CNI isn't completely broken - it still works using
 > the old-style linkage. However, if we dropped TREE_PUBLIC on
 > symbols then CNI would not work at all because CNI code is always
 > in a different translation unit to the corresponding Java class.
 > 
 > CNI is still useful with the BC-ABI even in its "broken" state,
 > provided CNI calls are used only within a given binary.

We have a real conflict between C (and C++) and the BC-ABI.  If we
don't make the symbols local, we have to link with -Bsymbolic, and
that breaks a bunch of C++ language features.

My best guess is that the BC-ABI will, for the time being, be used
mostly with "pure Java" and JNI applications.  If that's true, we can
either use -Bsymbolic or we can make symbols local.  Either will work
perfectly well.

So, I think we shouldn't change anything at all at this time.  Just
advise people compiling pure Java apps to use -Bsymbolic when linking
their libraries ... and advise people using CNI to wait until we've
fixed things before using the BC-ABI.

 > Also, making this change will prevent us from compiling libgcj with
 > the BC-ABI.

Sure, that's true.  But I'm not sure why that matters, and besides
there's no hurry to do so before CNI is fixed.

Andrew.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]