* Re: rhug under cygwin
2003-10-03 16:07 rhug under cygwin osml
@ 2003-10-04 16:58 ` Nicholas Wourms
0 siblings, 0 replies; 2+ messages in thread
From: Nicholas Wourms @ 2003-10-04 16:58 UTC (permalink / raw)
To: osml; +Cc: rhug-rhats, Tom Tromey
> 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: *** [lib-org-postgresql.la] Error 1
> make: 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
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.
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).
^ permalink raw reply [flat|nested] 2+ messages in thread