This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 1.3.20

Christopher Faylor wrote:
On Mon, Feb 03, 2003 at 02:33:20PM +0000, Jonathan Larmour wrote:

Chris Faylor wrote:

Besides Pierre's outstanding ntsec problems, are there other issues that
would hold up a release?
I just heard you're about to release this and was pointed this way. Can I ask you to hold off for a few hours at least?

I've been investigating a problem with building GDB under cygwin (pretty much any version - 5.2, 5.3, 5.3.1). It segfaults on startup.

My current theory is that vasprintf for newlib is broken, and needs to have the _file field of the FILE * initialised to some value.

Hmm.  Jason Tishler already tracked down a problem with vasprintf,
AFAIK.  It should be in cygwin snapshots.
Unfortunately that's an unrelated issue.

Can I suggest, discussing this in the newlib mailing list, if you think
it is a newlib problem?
The patch has indeed been submitted there now - no response yet.

It would be a shame to release a cygwin with a known serious (given the effect on GDB) bug.
It's a shame that you were discussing this on the ecos list for days
without notifying anyone in cygwin land.
If you mean that you saw my post on the ecos list at the end of last week, at that point we were not yet sure if it was GDB problem or a cygwin problem although we had our suspicions. It took a while to ascertain it was definitely a cygwin (specifically newlib inside cygwin) problem.

I'm sure you wouldn't appreciate bug reports about any GDB failures just because they are on cygwin :-).

BTW: I think there need to be some decent instructions on building the DLL

from source. I had various build failures with the 1.3.19-1 sources, like not having a declaration of gethostname(), and when doing a make install, cygrun.exe failing to link. I didn't bother fixing that.

Give me a friggin' break.  "/path/to/source/configure; make".  That's how
it works.  If it doesn't build for some reason, that's a bug.  Given
that I'm producing snapshots from the source base on a regular basis,
however, it's a strange bug.
I was building natively on cygwin. I can only report what I see. For the problem I am slightly mystified why you are indignant. It turns out I now see it was you that fixed this problem in CVS on 11th Jan in winsock2.h. As I said I was building from the 1.3.19-1 sources so this failure should surely not be a surprise to you.

What seems odd is that from the cvs log you fixed this before the cygwin 1.3.19 release, but that's easily explained: someone forgot to also release the corrected w32api package. Since this bug (minor though it is) prevents cygwin building, I encourage the person responsible (you or whoever) to do so, so that builds work for the net.

I also had to symlink winsup/w32api to the separate w32api package sources.
Ah, so you are using an older version of gcc.
No, the current GCC (3.2) that cygwin's setup.exe lets me download.

The reason is this in winsup/

if test -d $srcdir/w32api; then
echo "*** missing w32api directory" 1>&2
exit 1

Since cygwin and w32api source packages are distributed separately the test fails. A symlink obviously fixes this once you see that this is what is going on. This should probably be documented rather than trying to make some clever fix to scan directories matching /usr/src/w32api*. Easiest is probably just a note in the FAQ at <>.

For the failing build of cygrun.exe, I see in the current CVS that Corinna moved it to the testsuite, so that's no longer a problem

(And indeed there was a problem: cygrun is a mingw app, but used $(CC) which defines all the cygwin include path headers before any of the mingw ones. This resulted in an unresolved reference to _impure_ptr). I don't see how you could have built it in the same environment without hitting that problem. Unless you change something in your environment like overriding $(CC). I didn't think cygwin used cross builds for releases any more either.)

Whatever way, I don't believe your tone was warranted.

Oh, and configuring with --prefix <blah> doesn't work, although --prefix=<blah> does :-).
What in the world, are you talking about?  Are you completely unfamiliar
with autoconf?  Do you think that cygwin has some special version of
If you're referring to autoconf always preferring to document the --prefix=<blah> syntax by default. This is true, but --prefix <blah> has always worked elsewhere, and is meant to work - autoconf normally goes to great lengths to support it - and I just use it out of habit as bash didn't use to do filename completion after '='.

But anyway, I initially thought the problem was some failing customisation in w32api's configure scripts because that's where the build failed with a broken configure line. However now I see there have evidently been many recent changes to the top level configure files since both gcc 3.2.1 and gdb 5.3 which are both recent releases which worked with this syntax. It no longer uses the original "cygnus" configure but now autoconf. In particular the following script fragment in is very new, very bleeding edge (last changed 17th Jan) and very broken :-)...

baseargs=`echo " ${ac_configure_args} " | \
sed -e 's/ --no[[^ ]]* / /' \
-e 's/ --c[[a-z-]]*[[= ]][[^ ]]* / /' \
-e 's/ --sr[[a-z-]]*[[= ]][[^ ]]* / /' \
-e 's/ --ho[[a-z-]]*[[= ]][[^ ]]* / /' \
-e 's/ --bu[[a-z-]]*[[= ]][[^ ]]* / /' \
-e 's/ --t[[a-z-]]*[[= ]][[^ ]]* / /' \
-e 's/ -cache-file[[= ]][[^ ]]* / /' \
-e 's/ -srcdir[[= ]][[^ ]]* / /' \
-e 's/ -host[[= ]][[^ ]]* / /' \
-e 's/ -build[[= ]][[^ ]]* / /' \
-e 's/ -target[[= ]][[^ ]]* / /' \
-e 's/ [[^ -][^ ]*] / /' \
-e 's/^ *//;s/ *$//'`

The last expression strips unadorned options. This is the cause of the problem - it considers the prefix argument to be some sort of unadorned option. As a consequence baseargs gets set incorrectly causing problems further down the line when configuring subdirectories.

So again I don't think your tone was warranted - this isn't me being a dumb user with some basic autoconf misunderstanding - it's a specific problem with very recent changes in a customisation of

I will follow this up on binutils and gdb-patches lists as they claim responsibility for top level configure.

'Twould be good if this stuff was documented just in a or something.

Not gonna happen.  As is so often the case in cygwin land, you've fallen
into the trap of thinking "it must be hard, why don't they help me" rather
than "it works this way on unix, something must be broken <in my installation>".
No. I prefer not to let people hit the same problems over and over again. *I* am perfectly capable of solving the problems, but other people aren't. And indeed *I* already had solved the problems for myself.

I would be grateful in future if you could remember that some people reporting problems are not dumb, are perfectly capable of solving these problems, and are prepared to help fix them for the benefit of others in future. And not all problems are intrinsically the fault of the reporter just because they aren't the experiences in different environments.

eCosCentric <>
--[ "You can complain because roses have thorns, or you ]--
--[ can rejoice because thorns have roses." -Lincoln ]-- Opinions==mine

Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]