Subject: Re: psiconv on Windows
From: Tom Briggs (tom@sane.com)
Date: Thu Jan 25 2001 - 17:16:45 CST
> Thanks for testing this extensively! I am rather encouraged that the
> problems you note are not in the code itself, but in the build system,
> and even then mostly with its integration into the AbiWord build system.
I actually didn't even have to look at the code, which is a good sign. :)
As you noted, all the problems were with AbiWord integration.
> > The compilation problems were due to a incorrect include paths in a couple of
> > the makefiles. Simple enough, already taken care of.
>
> Were the fixes in the abi tree or in the psiconv tree? Did you commit
> them yet?
The fixes were to the abi tree, and yes, they've already been committed.
I apparently broke rule #1 of committing anything to CVS: post a message to
the list. :) Sorry 'bout that.
> > The larger problem, however, is linking. The core of the problem is that
> > psiconv is compiled as an XP library (in src/config/require/xp/Makefile), not a
> > platform specific library (like wv or iconv, in src/config/require/XX/Makefile).
>
> True. This may be a mistake by me due to an imperfect understanding of
> the AbiWord build system. As it is the idea that psiconv is used on all
> platforms, I thought it would be less work to put it into the xp/Makefile,
> instead of in all the XX/Makefile's.
I understand full well why you placed it in XP. I most likely would have
done the same thing. Unfortunately, you can't specify a platform-specific
compiler in an XP makfile, so that theory falls apart rather quicky. :)
> > This causes configure to make all it's choices based on the cygwin environment,
> > rather than based on information passed to it;
>
> Unless there happen some strange things underwater, I don't see this
> as the reason. I'd rather think that I need to add some autoconf-
> variables to detect the proper environment. Unlesss cl.exe does
> something really weird.
cl.exe uses different include and lib paths than does gcc - hence the reason
that gcc can find unistd.h and cl.exe cannot (and hence the reason that the
config.h in the psiconv directory #defines HAVE_UNISTD_H).
> > in addition, the generated
> > Makefile is used for compilation rather than a predefined Makefile.abi. This
> > results in a build process that's incompatible with AbiWord's, primarily
> > because psiconv gets built with gcc instead of the MSVC compiler.
>
> Hmm. I would still think that it should not be so hard to force it to
> use the right compiler. It is a pity I do not have a Windows computer
> within the proper enviroment to play around with it. However, if you
> are willing to help me run a few tests, and have autoconf, automake
> and libtool installed, we could try to solve this together.
I think that my original comment was both poorly worded and possibly flat
out wrong. From what I could see, all the other libs use a Makefile.abi to
build the libs for AbiWord's purposes - using all the abi defines, flags,
etc., naming the resulting library Abi_libXX and putting the resulting lib in
a specific obj directory somewhere. (Note that this has nothing to do with
the compiler, so my original comments were definitely way off. :) ) I think
that this type of makefile would be preferable for reasons that I'll get to
in just a minute.
> > On a related note: the linker flags for psiconv aren't currently specified
> > correctly, so any linker errors you see for the Win32 tinderbox build are
> > related to that (the EXTRA_LIBS var isn't an LDFLAGS equivalent, and isn't
> > intended to be passed to the linker verbatim). It isn't until after you resolve
> > the LDFLAGS vs. EXTRA_LIBS problem that you begin to see the gcc vs. MSVC
> > problems.
>
> Yes, I mentioned this in an earlier email. If you can tell me the
> Windows way of doing things, I can easily prepare a patch.
I just went back and looked at how EXTRA_LIBS is defined and used, and I
was partially incorrect on this one as well. EXTRA_LIBS appears to be a list
of libs that should be linked into AbiWord. On *nix platforms, this is
accomplished by turning them into command line args; -llibname, for example.
On Windows, they're transformed into the full path and file name of the lib
to be linked in, and are passed as such on the command line. So, the extension
of EXTRA_LIBS to include the linker flags works just dandy on *nix platforms,
but causes Windows to blow up altogether - -L isn't a command line option on
Windows, nor is /abi/psiconv/psiconv/.libs/ a valid path. :)
Now. The addition of the psiconv linker info to the EXTRA_LIBS var can
be moved to the LDFLAGS var. The Makefile in the wp/main/win/ then has to be
modified to transform the contents of the LDFLAGS into valid DOS pathnames.
(This strikes me as wrong, since they're supposed to be flags, not path names.)
Then, theoretically, a psiconv built with MSVC can be linked into AbiWord.
Have I just outlined all the work necessary to get psiconv linked into
AbiWord? Yes. Will it work? Probably. Do I like it? No. I think that
hacking a half-dozen different files just to "make it work" is the wrong
WrongThingToDo. I think that changing things around so that psiconv is built
and linked like all the other libs is the RightThingToDo[tm]. Since I'm not in
a position to tackle what I consider to be the proper fix, I haven't
attempted to implement it (though I will be more than happy to test it).
Here's an interesting question: when we build AbiWord on say, Linux, for
distribution, do we build it with zlib and psiconv linked in statically? If
so, under what circumstances are those libs (and expat and wv and libpng and
libiconv, for that matter) loaded dynamically? Only when compiling from source?
-Tom
This archive was generated by hypermail 2b25 : Thu Jan 25 2001 - 17:17:52 CST