Mail Archives: cygwin/2003/02/04/20:07:49
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
>
>>net.cc 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
net.cc 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/configure.in:
if test -d $srcdir/w32api; then
SUBDIRS="w32api $SUBDIRS"
else
echo "*** missing w32api directory" 1>&2
exit 1
fi
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 <http://cygwin.com/faq/faq_4.html#SEC103>.
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
> configure?
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 configure.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 configure.in.
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 README.build 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.
Jifl
--
eCosCentric http://www.eCosCentric.com/ <info AT eCosCentric DOT com>
--[ "You can complain because roses have thorns, or you ]--
--[ can rejoice because thorns have roses." -Lincoln ]-- Opinions==mine
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -