This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java 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: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows


Charles Wilson wrote:
Why was this necessary:

	<libjava/libltdl>
	* ltdl.c (DLL_EXPORT): Rename to LIBLTDL_DLL_EXPORT.
	* ltdl.h (DLL_EXPORT): Rename to LIBLTDL_DLL_EXPORT.

AFAIK, this new symbol LIBLDL_DLLEXPORT, is never defined by libtool,
even when building libjava shared.  So the symbols decorated with
LT_SCOPE will never get the __declspec(dllexport) annotation.

Or was that the intention, in order to work around the issue where ld
disables its default auto-export behavior, when it sees ANY symbol
explicitly marked as __declspec(dllexport)?

Yes. Sorry, I forgot to mention this. In addition, we specifically do not want this function to be exported from the DLL at all. See below.


If so, then the comment:
+#  ifdef LIBLTDL_DLL_EXPORT /* defined by libtool (if required) */
is wrong; it should be something like
   /* !not! 'DLL_EXPORT'; we don't want libtool to
      automatically decorate just these exports without
      also decorating every other libjava export
   */

OK, I will fix this comment to reflect the purpose of this name change.


But finally, there's one last issue: I thought one of the gcc guidelines
going forward with respect to autotools was to NOT modify imported
files.  These changes will be lost every time somebody resyncs with
upstream libtool...

The new libltdl does not have this issue. I have no idea why we're stuck with the 1.5 version of libltdl even though we're using a recent libtool.


However, libltdl seems to have been modified in similar ways by other people; just look at the ChangeLog. Since everyone else is modifying this, and this is not an issue in the upstream version, I think this is the best change.

Updating to a newer libltdl would probably be good, since I suspect there are Windows-specific improvements in it. However, libjava would need to be ported to it, since its currently dependent upon interfaces that have been removed in newer versions of libltdl. There may also be other reasons we're still using this old version of libltdl.

Wouldn't it make more sense, until there are proper __declspec()
markings/macros on all desired libjava exports, to leave these source
files alone and just explicitly use -Wl,--enable-auto-export when
linking the libjava DLL on mingw/cygwin?

I don't like this solution as much, as these exports really are not dllexport, and we specifically do not want them to be exported--even though we are doing nothing at present to prevent this. (As I mentioned previous, a future patch will fix this symbol leakage.) For this reason, I think it's important we completely avoid marking these dllexport, beyond fixing this specific issue.


If it's all the same to you, I like my solution better. :) Let me know if you still feel differently, and maybe we can talk more.


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