public inbox for
 help / color / mirror / Atom feed
From: Nicholas Wourms <>
Cc:, Tom Tromey <>
Subject: Re: rhug under cygwin
Date: Sat, 04 Oct 2003 16:58:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> 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 `' 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]: *** [] 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, 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, 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, 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'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).


      reply	other threads:[~2003-10-04 16:58 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-03 16:07 osml
2003-10-04 16:58 ` Nicholas Wourms [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).