This is the mail archive of the rhug-rhats@sources.redhat.com mailing list for the RHUG 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: rhug under cygwin


osml@stratej.com wrote:
I've been playing around with building rhug under cygwin. More specifically,
I'm trying to build pgsql-jdbc.


It makes it through most of the build and then fails in the libtool linking
phase with the following error message:

libtool: link: cannot build libtool library `lib-org-postgresql.la' from
non-libtool objects on this host: errors.o errors_de.o errors_it.o
errors_zh_TW.o errors_fr.o errors_nl.o
make[1]: *** [lib-org-postgresql.la] Error 1
make[1]: Leaving directory `/workplace/rhug/pgsql-jdbc'
make: *** [all] Error 2

The errors*.o files look like they are --resource files generated with gcj.  Is
there a compatibility problem between libtool and these objects?

Has anybody been able to build rhug under cygwin? Am I missing a step?


Actually, I been looking at it off & on over the last year. However, now that Cygwin finally has gcj-3.3.1, any compile issues should be fixed.


The problem, as you have noted, is how libtool deals with non-libtool objects. In linux, it returns an error "This is not portable", however it gives an error in cygwin. I believe this is due to the fact that Cygwin uses a different algorithm to determine what kind of object and object really is. Conversely, in linux, dependancy objects are marked "pass all", so it doesn't fail.

Recently, I've been investigating possible solutions. Two things I think are needed in RHUG for it to build properly:

1)RHUG's templates ***MUST*** be upgraded to use CVS libtool head, automake-1.7.7, and autoconf 2.57. Frankly, there is really little excuse to be using the ancient autotools, unless you are a masochist. The latest tools are a good idea for many reasons, the least amongst which is that the newer automakes handle gcj/java stuff better. Also, the libtool linking is much more refined and less prone to improper dependency linking. This should be relatively easy since libtool head can deal with gcj just as effectively as the hacked libtool currently in RHUG. Furthermore, additions can be made to source of the tools so that rules aren't being duplicated.

2)In the "xform" section of ltmain.sh, add a rule for '.res' and '.property' files (see the "suffix test" in the libtool tarball). This will tell libtool to also generate .lo scripts instead of just the .o object. To be even more exact, we should add the necessary rules to automake such that one can just put the '.res' and '.property' objects into the _la_SOURCES line and automake will autogenerate the proper rule for building all the files with libtool & gcj as well as generating the headers.

For automake (looking in automake.in), in terms of dealing with header generation, I suggest that we copy the way YACC source is handled (since what we are doing is quite similar (preprocessing java files to generate more source files)). We can then add a new register_language, 'javaprop', which would provide the rules for compiling and linking files with the .res/property extension (I suggest emulating the template for Preprocessed F77). I think we may also need to add an entry to lang-compile.am, but I'm not sure...

There is still an underlying problem for Cygwin, which is that the various libgcj libraries are built static. This makes the RHUG binaries outrageously huge on this platform, not to mention causes all sorts of problems with re-exporting symbols from the static archive in an external shared library. Unfortunately, we will NOT be able to build shared versions of the libgcj libraries (dlls) until someone friggin' updates those ancient versions of the autotools in the GCC build tree and backports the changes to the 3.3 branch. If I wasn't clear earlier, then let me be clear now, libtool-1.4x will *NOT* generate proper shared libraries with the current toolchain on Cygwin. In fact, it's hopelessly beyond patching up (believe me, I've tried), which is why I push for libtool-1.5.

<RANT>
I don't want to get off on a rant here, but for the life of me I can't understand why some of the autotool experts (like Gary V., Akim D., etc.) haven't pitched in to convert the gcc tree by now. I mean, since they basically wrote the tools, I would think that they would be the ones most qualified in converting that mess of a tree in the shortest time possible (it should be a cakewalk?)... Since GCC is used by everyone, I can't see why it wouldn't be in their best interest to help... This is my opinion, but the conversion shouldn't be taking as long as it is. Frankly, given the age of the tools, I suprised by the reluctance to move forward. If anything, using the newer autotools would cut out the useless redundancy present in the current tree and make the templates *much* more readable. Ditching the custom Makefile.in's and aclocal's would also be a godsend. Alas, it is wishful thinking, and until we can get libtool-1.5.1 in the gcc tree, I guess we'll have to settle on static for now :-/ (grrrrrrr....).


That being said, I'm not trying to attack anyone, per se. I'm grateful for the time and effort put into making these tools and RHUG. It's just frustrating, though, when you are stuck with tools that don't work right and a mess of macros and intricate build rules which make updating very hard for the average person (I've tried, but debugging m4 errors/oddities often makes me want to pull my hair out and scream, thus I usually loose interest 6 hours into it).
</RANT>


Cheers,
Nicholas


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