Re: Cygwin ping!

Olaf Weber writes:

> Well, I haven't done much except ponder things where cross-compiling
> is concerned.  The present state of my thoughts on the matter is that
> I'd like to simplify the build (and cross-building) a bit.

Ok.  It's grand to see that only one or two main issues remain.

> With Jan's current patch, a native libkpathsea has to be installed
.
> I'd like to change this to simply require that 'tangle', 'ctangle',
> 'otangle', and 'tie' be installed.

This feels a bit like a step backwards, and I also do not see the big
difference between the requirement of a library and some programs that
use it?  But if you like to change it, that's of course perfectly fine
with me, you really do not need to ask my approval; my main concern is
for the cross building to work.

I would advise and ask you to just make the change and not wait or
ponder too long though; the forward porting the patch (from 2.96.1 to
2.96.4 this time, find attached) just ate yet another hour because of
silly conflicts :-(

> The other main concern is that the windows idiom used to determine
> the exports/imports, which currently is like this:

[ current code snippet ]

That's how I read it.

> (With the note that current makefiles do not provide any of these
> defines.)  I note that you're changing this idiom.  Doesn't this work
> for Cygwin?

No, it doesn't.  That's the first thing I tried, of course.  Luckily,
it is all explained in the GNU ld info pages, from where I simply
copied my solution.  (short explanation: current code is almost ok,
but Cygwin does not want dllexport.)

It only differs from the ld manpage example (and the way I did it for
GUILE) in the ability to still define __dllexport, because this is
what the Windows code did, and I did not want to touch that.

I'm a bit surprised by your question, as it looks as such a simple,
minor thing and that nonwithstanding we went through all these motions
before (twice, IIRC.  My first patch implemented this all for
klibtool, my second one had to be updated for libtool).  Last time,
you noticed that I accidentally unintentionally probably *did* change
the Windows behaviour, which I promptly fixed in a next patch.

I thought that we were (almost, waiting for a sign of life from the
Windows team again) OK now on this issue?

Greetings,
Jan.



[Previous discussion on this, for completeness

> > > > 11 - Given 10, I do not understand why KPSEDLL_EXPORT is introduced.
> > 
> > Cygwin is a unixoid, mostly.  That's why a lot of GNU/Unix packages
> > build out of the box on Cygwin nowadays and I'd like for teTeX/web2c
> > to do that too.  When it does, I can easily hand over the Cygwin
> > maintenership to someone else.
> > 
> > Shared library import/export symbols need special attention, but
> > Cygwin is *not* (like) Windows.  I introduced KPSEDLL_EXPORT to get
> > the shared library to build, in compliance with the binutils's `man
> > ld' (Cygwin must only have dllimport, not dllexport) nand took special
> > care not to change the behaviour for plain Windows builds.
> > 
> > I was not aware of a Windows makefile patch; noticing *KPSE_DLL stuff
> > I assumed it would `just work' for plain Windows builds.  I would
> > suggest to either include the plain windows makefile patches, or to
> > junk the remains of them and only include Cygwin build.
> > 
> > > 12 - The KPSEDLL_EXPORT changes to c-proto.h and getopt.h look likely
> > >      to break Fabrice's method for building libkpathsea.dll (as per
> > >      the method described in 10 above).  This is a definite nono.
> > 
> > As far as I can see, you _did_ change the behaviour for plain Windows
> > builds.  Please note that the windows builds don't use the Makefiles
> > you find in the source tree.  Fabrice doesn't use make, and has his
> > own set of "things-that-are-almost-makefiles".
> 
> I was not aware of a Windows makefile patch; noticing *KPSE_DLL stuff
> I assumed it would `just work' for plain Windows builds.  I would
> suggest to either include the plain windows makefile patches, or to
> junk the remains of them and only include Cygwin build.

The suggestion that the Windows team possibly does not even use make,
but probably maybe uses some third party build scheme that apparently
cannot be tested, adapted, updated or fixed, thus no-one dares to
touch anything that comes close, would make me, as a project leader,
very nervous and would be something I would see to get fixed asap.]

-- 
Jan Nieuwenhuizen <[email protected]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org