rhug under cygwin

rhug under cygwin

[osml]

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? 

Thanks in advance,

Jason

Re: rhug under cygwin

[Nicholas Wourms]

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