Re: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2

[Yaakov (Cygwin Ports)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Charles Wilson wrote:
| Looks like a gettext bug to me. Might be fixed in 0.16+, but please
| report upstream.

I'll admit I'm not that fluent in gettext internals.  Obviously both
macros are supposed to be present; is having only one just old
behaviour, or simply broken?

| That's bizarre.  Also, I believe that config.rpath may have a bug:
|
| -shrext=.dll
| +shrext=.dll.a
|
| because the result of config.rpath is used to probe /usr/lib, not
| /usr/bin...BUT shrext is a widely used variable, and is not namespaced.
|  No telling WHAT that change might break, which is why I haven't
| reported this as a "bug".  But I did have to impose that patch in the
| alternatives cygport, because otherwise I was forced to link statically
| to libintl and libiconv.

Trust me, I've always found this extremely annoying.  The alternative
(no pun intended) is to use $(LTLIBINTL) instead of $(LIBINTL), but that
can require a lot of Makefile patching.  Fixing this would be a blessing.

AFAICS there shouldn't be any namespacing problems with shrext, because
config.rpath is run as a script, not sourced as a macro; the value is
exported as acl_cv_shlibext.  So I'd say, go for it.

| You don't want much, do you?

Of course I do. :-)

| This is a apparently not a libtool-2.2 issue; if gettext is broken or
| invoked incorrectly, AND shares some variables in the same namespace as
| libtool, AND clobbers them...the only thing that can be done there is to
| ensure that libtool never ever uses any variables outside the lt_
| namespace.
|
| There's been a lot of work done to try to make libtool namespace clean
| and insensitive to variables outside lt_ -- but there's still quite a
| bit to be done.  One of the problems is the .la file format is fixed,
| and the variables there are *not* in the lt_ namespace; there's no help
| for that, except a format change.

OK, but libext is not exported to the .la file.  Being that libext keeps
getting clobbered in different ways, I would look into namespacing it if
at all possible.


Yaakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkgRXFwACgkQpiWmPGlmQSPCWwCfXDH5Fj5vN1h4dQU9X37O+Emr
YREAn3Zk+B7z+m9odHCxf7LWeT08UyyJ
=i2LD
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2

[Yaakov (Cygwin Ports)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Charles Wilson wrote:
| Well, that's not enough information at all. The c++ tests all pass, so
| I'm going to need a testcase or at least the actual project you're
| building that gives this error.

.cygport attached, as well as the diff between the libtools generated by
config.lt and config.status.  Let me know if you need more info.


Yaakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkgRVN8ACgkQpiWmPGlmQSMq/QCfRLGUBl4McJLhETHVo1tjIAxp
weMAoJ36OFitVIgZP2Bd2Qc8I3qAKNWS
=64qn
-END PGP SIGNATURE-
--- libtool-1   2008-04-24 22:42:28.046875000 -0500
+++ libtool-2   2008-04-24 22:41:52.609375000 -0500
@@ -1,7 +1,7 @@
 #! /bin/sh
 
 # libtool - Provide generalized library-building support services.
-# Generated automatically by config.lt (xapian-core) 1.0.6
+# Generated automatically by config.status (xapian-core) 1.0.6
 # Libtool was configured on host YAAKOV03:
 # NOTE: Changes made to this file will be lost: look at ltmain.sh.
 #
@@ -34,7 +34,7 @@
 
 
 # The names of the tagged configurations supported by this script.
-available_tags=""
+available_tags="CXX "
 
 # ### BEGIN LIBTOOL CONFIG
 
@@ -129,7 +129,7 @@
 old_postuninstall_cmds=""
 
 # A C compiler.
-LTCC="gcc"
+LTCC=""
 
 # LTCC compiler flags.
 LTCFLAGS="-O2 -pipe "
@@ -391,6 +391,20 @@
 # How to hardcode a shared library path into an executable.
 hardcode_action=immediate
 
+# The directories searched by this compiler when creating a shared library.
+compiler_lib_search_dirs=""
+
+# Dependencies to place before and after the objects being linked to
+# create a shared library.
+predep_objects=""
+postdep_objects=""
+predeps=""
+postdeps=""
+
+# The library search path used internally by the compiler when linking
+# a shared library.
+compiler_lib_search_path=""
+
 # ### END LIBTOOL CONFIG
 
 # Generated from ltmain.m4sh.
@@ -8276,3 +8290,158 @@
 # End:
 # vi:sw=2
 
+
+# ### BEGIN LIBTOOL TAG CONFIG: CXX
+
+# The linker used to build libraries.
+LD="/usr/i686-pc-cygwin/bin/ld.exe"
+
+# Commands used to build an old-style archive.
+old_archive_cmds="\$AR \$AR_FLAGS \$oldlib\$oldobjs~\$RANLIB \$oldlib"
+
+# A language specific compiler.
+CC="g++"
+
+# Is the compiler the GNU compiler?
+with_gcc=yes
+
+# Compiler flag to turn off builtin functions.
+no_builtin_flag=" -fno-builtin"
+
+# How to pass a linker flag through the compiler.
+wl="-Wl,"
+
+# Additional compiler flags for building library objects.
+pic_flag=" -DDLL_EXPORT -DPIC"
+
+# Compiler flag to prevent dynamic linking.
+link_static_flag="-static"
+
+# Does compiler simultaneously support -c and -o options?
+compiler_c_o="yes"
+
+# Whether or not to add -lc for building shared libraries.
+build_libtool_need_lc=no
+
+# Whether or not to disallow shared libs when runtime libs are static.
+allow_libtool_libs_with_static_runtimes=yes
+
+# Compiler flag to allow reflexive dlopens.
+export_dynamic_flag_spec="\${wl}--export-dynamic"
+
+# Compiler flag to generate shared objects directly from archives.
+whole_archive_flag_spec="\${wl}--whole-archive\$convenience 
\${wl}--no-whole-archive"
+
+# Whether the compiler copes with passing no objects directly.
+compiler_needs_object="no"
+
+# Create an old-style archive from a shared archive.
+old_archive_from_new_cmds=""
+
+# Create a temporary old-style archive to link instead of a shared archive.
+old_archive_from_expsyms_cmds=""
+
+# Commands used to build a shared archive.
+archive_cmds="\$CC -shared -nostdlib \$predep_objects \$libobjs \$deplibs 
\$postdep_objects \$compiler_flags -o \$output_objdir/\$soname 
\${wl}--enable-auto-image-base -Xlinker --out-implib -Xlinker \$lib"
+archive_expsym_cmds="if test \\\"x\\\`\$SED 1q \$export_symbols\\\`\\\" = 
xEXPORTS; then
+   cp \$export_symbols \$output_objdir/\$soname.def;
+  else
+   echo EXPORTS > \$output_objdir/\$soname.def;
+   cat \$export_symbols >> \$output_objdir/\$soname.def;
+  fi~
+  \$CC -shared -nostdlib \$output_objdir/\$soname.def \$predep_objects 
\$libobjs \$deplibs \$postdep_objects \$compiler_flags -o 
\$output_objdir/\$soname \${wl}--enable-auto-image-base -Xlinker --out-implib 
-Xlinker \$lib"
+
+# Commands used to build a loadable module if different from building
+# a shared archive.
+module_cmds=""
+module_expsym_cmds=""
+
+# Whether we are building with GNU ld or not.
+with_gnu_ld="yes"
+
+# Flag that allows shared libraries with undefined symbols to be built.
+allow_undefined_flag="unsupported"
+
+# Flag that enforces no undefined symbols.
+no_undefined_flag=""
+
+# Flag to hardcode $libdir into a binary during linking.
+# This must work even if $libdir does not exist
+hardcode_libdir_flag_spec="-L\$libdir"
+
+# If ld is used when linking, flag to hardcode $libdir into a binary
+# during linking.  This must work even if $libdir does not exist.
+hardcode_libdir_flag_spec_ld=""
+
+# Wh

[ANNOUNCEMENT] Updated: {pcre,libpcre0,pcre-devel,pcre-doc}-7.6-2

[Yaakov (Cygwin Ports)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The following packages have been updated in the Cygwin net release:

+++ libpcre0-7.6-2
+++ pcre-7.6-2
+++ pcre-devel-7.6-2
+++ pcre-doc-7.6-2

This is an upstream version bump.  Cygwin-specific changes:

* Patch from Gentoo for libpcrecpp compatibility with pre-7.6.
* Avoid unnecessary dependency_libs in libpcre*.


Yaakov

*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

[EMAIL PROTECTED]

If you need more information on unsubscribing, start reading here:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkgRUJsACgkQpiWmPGlmQSP+DQCgrbYpMZ4nOXh+N3XNS6i2ctLf
9ZwAnjdCRbJ77OlM6pTRzUhs0xd3Aynf
=coUH
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

[ANNOUNCEMENT] Updated: cygport-0.3.9-1

[Yaakov (Cygwin Ports)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The following package has been updated in the Cygwin net release:

+++ cygport-0.3.9-1

Overview of changes since 0.3.8:

* UNSTABLE API: src_unpack_hook and src_patch_hook
* Allow multiple postinstall/preremove scripts for split packages.
* Now compatible with libtool-2.2.
* Support .tar.lzma source archives.
* gst-plugins0.10.cygclass: Update for gst-plugins-bad-0.10.6.
* gtk2-perl.cygclass: Fix for perl-5.10.
* hg.cygclass: NEW for Mercurial repository checkouts.
* perl.cygclass: Fix for perl-5.10.



Yaakov

*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

[EMAIL PROTECTED]

If you need more information on unsubscribing, start reading here:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkgRT/8ACgkQpiWmPGlmQSN9GACfUI/RlcOwkHLZZ9BB5+l45/FT
Sp4AoJL8inVnQJP2lzQPAaMwedUF7XJg
=cuua
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: [ANNOUNCEMENT] Updated: inetutils-1.5-3

[Yaakov (Cygwin Ports)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Charles Wilson wrote:
| Yep, looks like that will work -- once 0.3.9 is out. However, the
| inetutils-1.5-3 cygport file *as released* requires a function in
| neither the official cygport-0.3.8 nor the upcoming cygport-0.3.9. So,
| *as released*, inetutils-1.5-3 needs a patched cygport.
|
| inetutils-1.5-4 won't.

Fair enough.  I just uploaded 0.3.9, so you should be able to start
porting your customized .cygport's for it.

Are there any other features you still need?

| Of course, if you use the absolute path to the target, you avoid all
| that. 
|
| Yours (origsrcdir):
| (cd headers/arpa  && ln -s ${C}/arpa/tftp.h .)
|
| Yeah. Like that. Still, dangling symlinks are ugly. But your solution
| with (temporarily) dangling symlinks and src_unpack_hook() is much less
| ugly that my "be sure to duplicate all actions in both src dirs".

As they say, KISS. :-)


Yaakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkgRUuEACgkQpiWmPGlmQSNwVQCgmau73/QBHYAiSrao3h3q4scb
RCQAnjm9R+JHiFRALGfNukYt2rbtCHl3
=O1A0
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2

[Charles Wilson]

Yaakov (Cygwin Ports) wrote:

Here's yet another interesting case with libtool-2.2:


"interesting", as in "may you live in interesting times"?


/bin/sh ../../libtool --tag=CXX --mode=link g++  -O2 -pipe-o
libfoo-1.2.la -rpath /usr/lib -no-undefined sources.lo
libtool: link: rm -fr  .libs/libfoo-1.2.dll.a .libs/libfoo-1.2.la
.libs/libfoo-1.2.lai
libtool: link: g++ -shared -nostdlib   .libs/sources.o
-L/usr/lib/gcc/i686-pc-cygwin/3.4.4
-L/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../.. -lstdc++ -lgcc -lcygwin
-luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc -o
.libs/cygfoo-1.2-0.dll -Wl,--enable-auto-image-base -Xlinker
--out-implib -Xlinker .libs/libfoo-1.2.dll.a
Creating library file: .libs/libfoo-1.2.dll.a
libtool: link: ar cru .libs/libfoo-1.2.  sources.o
libtool: link: ranlib .libs/libfoo-1.2.
libtool: link: ( cd ".libs" && rm -f "libfoo-1.2.la" && ln -s
"../libfoo-1.2.la" "libfoo-1.2.la" )

In this specific case, the static library is missing the ".a" extension
(Windows ignores the final dot, as usual).  Here's why:

This package had AM_GNU_GETTEXT in configure.ac without any arguments
nor AM_GNU_GETTEXT_VERSION.  autoreconf decided "not using Gettext"[1]


> [1] autoreconf decided "not using Gettext" because it looks solely for
> AM_GNU_GETTEXT_VERSION to make that determination.  (It only looks for
> AM_GNU_GETTEXT to see if one of these two is used without the other,
> and emits a warning if so.)

Looks like a gettext bug to me. Might be fixed in 0.16+, but please 
report upstream.


and didn't install config.rpath[2]. 


> [2] lib-link.m4 0.15 adds a line telling automake >= 1.10 that
> config.rpath is required, but this package was using 1.9.  In
> any case, this macro was from 0.11.2, which preceded automake-1.10.

That's bizarre.  Also, I believe that config.rpath may have a bug:

--- config.rpath2008-04-16 03:59:54.87500 -0400
+++ config.rpath2008-04-16 04:00:04.546875000 -0400
@@ -501,7 +501,7 @@
   bsdi[45]*)
 ;;
   cygwin* | mingw* | pw32*)
-shrext=.dll
+shrext=.dll.a
 ;;
   darwin* | rhapsody*)
 shrext=.dylib

because the result of config.rpath is used to probe /usr/lib, not 
/usr/bin...BUT shrext is a widely used variable, and is not namespaced. 
 No telling WHAT that change might break, which is why I haven't 
reported this as a "bug".  But I did have to impose that patch in the 
alternatives cygport, because otherwise I was forced to link statically 
to libintl and libiconv.


Also, 'alternatives' is a wierd case -- I had to hack it to death since 
it's not actually a package of its own; it's really 'chkconfig'. So I 
decided not to draw any wide-ranging conclusions about config.rpath from 
any issues involving the alternative package.



But AC_LIB_RPATH (from the included
gettext-0.11.2 lib-link.m4) was called; while nothing happened due to
the missing config.rpath, it then defined libext=$acl_cv_libext, which
had never been defined.  This empty $libext clobbered that of libtool.

In this case, the solution was simply to call AM_GNU_GETTEXT_VERSION.
But this is the second case where libtool's had its variables clobbered
by other parts of configure.  Could something be done to make sure that
that can't happen?


You don't want much, do you?

This is a apparently not a libtool-2.2 issue; if gettext is broken or 
invoked incorrectly, AND shares some variables in the same namespace as 
libtool, AND clobbers them...the only thing that can be done there is to 
ensure that libtool never ever uses any variables outside the lt_ namespace.


There's been a lot of work done to try to make libtool namespace clean 
and insensitive to variables outside lt_ -- but there's still quite a 
bit to be done.  One of the problems is the .la file format is fixed, 
and the variables there are *not* in the lt_ namespace; there's no help 
for that, except a format change.


--
Chuck

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2

[Charles Wilson]

Yaakov (Cygwin Ports) wrote:

* libtool should catch if the lt-foo.c compile fails;


Yes. I haven't tracked this one down yet.


I think I have also found a separate case of breakage when the CXX tag
is enabled, in which case LTCC is mysteriously undefined.  The results:

./libtool: line 7737: -O2: command not found
strip: './foo.exe': No such file
./libtool: line 7748: $func_ltwrapper_scriptname_result: ambiguous redirect


Well, that's not enough information at all. The c++ tests all pass, so 
I'm going to need a testcase or at least the actual project you're 
building that gives this error.


--
Chuck

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2

[cygwin]

Charles Wilson wrote:

Yaakov (Cygwin Ports) wrote:

./.libs/lt-foo.c:263: warning: string length `4368' is greater than the
length `4095' ISO C99 compilers are required to support


This one can be fixed by splitting the string into two pieces. I'm 
working on a patch for that.



./.libs/lt-foo.c: In function `main':
./.libs/lt-foo.c:288: warning: implicit declaration of function 
`_setmode'


This one is already fixed in current git.


./.libs/lt-foo.c: In function `chase_symlinks':
./.libs/lt-foo.c:577: warning: implicit declaration of function 
`realpath'

./.libs/lt-foo.c:577: warning: assignment makes pointer from integer
without a cast


These two are the same issue...
(1) realpath() is invoked in a section of code that is #ifdef __CYGWIN__
(2) the wrapper source code unconditionally #includes stdlib.h
(3) cygwin's stdlib.h declares realpath.

...but it does so inside a #ifndef __STRICT_ANSI__ block. And -std=c99 
turns on __STRICT_ANSI__, while -std=gnu99 does not.


Posix says that realpath() will be declared if #include 
Ansi says nothing about realpath(), so STRICT_ANSI requires that 
realpath is NOT declared when #include 


I guess the cwrapper should add a section like this, for __CYGWIN__

#if defined __CYGWIN__
# if defined __STRICT_ANSI__
char *realpath (const char *, char *);
# endif
#endif

NOTE: usually you *want* the cwrapper to be compiled with the same 
CFLAGS that your target application needs.  OTOH, if you explicitly set 
your compatibility flags (-c99, _POSIX_C_SOURCE=200112L, -ansi, etc) 
"too low" it is possible something's going to break.


Or some pathological project could put '-Dprintf=exit' into CFLAGS.  You 
can't guard against everything.


But we ought to be compatible with c99.

--
Chuck


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: [ANNOUNCEMENT] Updated: inetutils-1.5-3

[Charles Wilson]

Yaakov (Cygwin Ports) wrote:

[EMAIL PROTECTED] wrote:
| Building this package requires a patched cygport:
|   http://cygwin.com/ml/cygwin-apps/2008-03/msg00139.html

Are you sure?  AFAICS the attached WFM; I just need to update cygport in
the distro.


Yep, looks like that will work -- once 0.3.9 is out. However, the 
inetutils-1.5-3 cygport file *as released* requires a function in 
neither the official cygport-0.3.8 nor the upcoming cygport-0.3.9. So, 
*as released*, inetutils-1.5-3 needs a patched cygport.


inetutils-1.5-4 won't.

From an earlier thread:

You could create dangling symlinks, knowing that .cygwin.patch will

> eventually "undangle" them, but you can't do that before the ${S}
> directory is created/mirrored from ${origsrcdir} -- if you did, then
> the (dangling) symlinks created in ${origsrcdir} will be copied over
> to the ${S} as-is: with the incorrect relative path to
> CYGWIN-PATCHES/real-header-file. And deliberately creating dangling
> symlinks is just plain icky.

The problem I was trying to "solve" was that the relative path to the 
actual file was different depending on which directory you were in -- 
${S} or ${origsrcdir}/${SRC_DIR}


Mine ${origsrcdir}/${SRC_DIR}:
(cd headers/arpa && ln -s ../../../../src/${SRC_DIR}/CYGWIN-PATCHES
/arpa/tftp.h .)
This path, if mirrored to ${S}, would be wrong.

Mine ${S}:
(cd headers/arpa  && ln -s ../../CYGWIN-PATCHES/arpa/tftp.h .)

so both symlinks end up pointing directly to 
${top}/src/${SRC_DIR}/CYGWIN-PATCHES/arpa/tftp.h

using relative paths from their respective locations.

We can't do even the first part of the above before mirroring -- which 
means that src_unpack_hook is too early (as is src_patch_hook).



Of course, if you use the absolute path to the target, you avoid all 
that. 


Yours (origsrcdir):
(cd headers/arpa  && ln -s ${C}/arpa/tftp.h .)

Yeah. Like that. Still, dangling symlinks are ugly. But your solution 
with (temporarily) dangling symlinks and src_unpack_hook() is much less 
ugly that my "be sure to duplicate all actions in both src dirs".


--
Chuck


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: [ANNOUNCEMENT] Updated: inetutils-1.5-3

[Yaakov (Cygwin Ports)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

[EMAIL PROTECTED] wrote:
| Building this package requires a patched cygport:
|   http://cygwin.com/ml/cygwin-apps/2008-03/msg00139.html

Are you sure?  AFAICS the attached WFM; I just need to update cygport in
the distro.


Yaakov
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkgROyAACgkQpiWmPGlmQSPKpACgum+RmxkmWq5l/sYKj1fwa+Z/
P9IAoNyrZcc4tIw9syFYWJrirFS4QRyk
=fa1T
-END PGP SIGNATURE-
DESCRIPTION="A collection of clients and servers for internet communication"
HOMEPAGE="http://www.gnu.org/software/inetutils/";
SRC_URI="http://ftp.gnu.org/gnu/inetutils/${PN}-${PV}.tar.gz";

DIFF_EXCLUDES="ftpcmd.c"

CYGPORT_USE_UNSTABLE_API=1
RESTRICT="postinst_info"

src_unpack_hook() {
mkdir -p headers/arpa headers/protocols
(cd headers/arpa  && ln -s ${C}/arpa/tftp.h .)
(cd headers/protocols && ln -s ${C}/protocols/talkd.h .)
(cd headers/protocols && ln -s ${C}/protocols/osockaddr.h .)
}

src_compile() {
cd ${S}
cygautoreconf
cd ${B}
cygconf --disable-ipv6
cygmake
}

src_install() {
cd ${B}
cyginstall

dodoc ${S}/ChangeLog.* ${C}/${PN}.OLD-README ${C}/udp_client.c
dobin ${C}/iu-config ${C}/syslogd-config
dodir /usr/include/arpa /usr/include/protocols

insinto /usr/include/arpa
doins ${C}/arpa/tftp.h

insinto /usr/include/protocols
doins ${C}/protocols/talkd.h
doins ${C}/protocols/osockaddr.h

dodir /etc/rc.d/init.d
insinto /etc/rc.d/init.d
doins ${C}/inetd

dodir /etc/inetd.d
keepdir /etc/inetd.d
dodir /etc/defaults/etc
insinto /etc/defaults/etc
doins ${C}/defaults/ftpusers ${C}/defaults/ftpwelcome
doins ${C}/defaults/inetd.conf ${C}/defaults/shells
doins ${C}/defaults/motd ${C}/defaults/syslog.conf

rm -f ${D}/usr/bin/ifconfig.exe
rm -f ${D}/usr/bin/logger.exe
rm -f ${D}/usr/bin/ping.exe
rm -f ${D}/usr/bin/whois.exe

rm -f ${D}/usr/share/man/man1/logger.1*
rm -f ${D}/usr/share/man/man8/ping.8*
}

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Looking for basic documentation on Cygwin and Serial Ports

[NightStrike]

On 4/24/08, Nefastor <[EMAIL PROTECTED]> wrote:
>
>
> Brian Dessent wrote:
> >
> > Nefastor wrote:
> >
> >> (...) I don't know which of Cygwin's /dev/tty device corresponds to which
> >> serial
> >> port on my PC (that is, I only know the COM port number). I can "sort of
> >> guess" /dev/tty0 is COM1, but that's a guess, and I'd prefer some
> >> certainty.
> >
> > Cygwin works the same as Linux, /dev/ttyS0 is the first serial device,
> > /dev/ttyS1 is the second, etc.  Please consult the users guide:
> > .
> >
> >
>
> That I have, Brian. What itches me is that I'm facing some kind of special
> case : My machine has two serial port, one on the MoBo and a USB-serial
> adapter, yet Windows calls them COM1 and COM3. I've searched the whole
> Device Manager but couldn't find any device that would be COM2. And I can
> rename COM1 to COM2.
>
> Speaking of Windows' DM, it's rather quirky on the serial ports : I noticed
> that if I unplug my USB cable (COM3) and try to change the name of COM1, in
> the drop down box COM3 is listed as "in use" :confused: %-|.
>
> So, I have a machine with two serial ports but no COM2, AND I can change the
> COM port number to whatever I want, plus Windows seems to have a bad case of
> "phantom limb syndrome". Getting back to your answer : how can know for sure
> what Cygwin calls "the first port", or "the second port" ?
>
> Trial and error is obviously not what I'm after, rather I need a way for my
> program to know for sure what port it's dealing with. To help me write that
> program I'd need to know :
>
> - is there a fixed relationship between COM port number "X" and dev/ttyS
> number "Y", such as Y = X - 1 ? For instance, if I change my COM port number
> from 3 to 7, will the dev/ttyS number go from 2 to 6, or will it remain
> unchanged ?
>
> - if it remains unchanged, I'm assuming Cygwin does some sort of port
> enumeration : is that process deterministic ?
>
> Additionally, can you point me to documentation on how to retrieve device /
> driver info from my program ? That way, worst case scenario, I can have the
> program look for the correct port on its own.
>
> Thank you for your time, I know I'm asking for a lot of stuff but I've got
> the feeling the answers would be useful to many.:-)

What motherboard do you have?  It's always possible that there is a
riser pinout for a serial port somewhere in the front of the board for
connection to a front panel mount.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

[ANNOUNCEMENT] Updated: pkg-config-0.23a-1

[cygwin]

The pkg-config program is used to retrieve information about installed 
libraries in the system, including the CFLAGS, LDFLAGS, and other 
information necessary to compile and link against one or more libraries.


CHANGES since 0.21-1

* update to latest bzr development version (2008-04-19)
* Still using --enable-indirect-deps
* rework cygport packaging, to adapt to bzr cygclass.

post 0.23 release:
===
  - Incorporate fixes for most of the earlier cygwin patches
  - logging support
  - 'conflicts' actually works, now

pkg-config 0.23
===
 - Add support for setting sysroot through PKG_CONFIG_SYSROOT_DIR in
   the environment.
 - Update included glib to 1.2.10.
 - Other minor fixes, including a segfault.

pkg-config 0.22
===
 - Make Requires.private a whole lot more useful by traversing the
   whole tree, not just the top-level, for Cflags.
 - Add support for using the system glib.
 - Update URL to pkg-config website
 - Fix some win32 problems.
 - Other minor fixes.


Note that the new "private libs" and "private requires" features do not 
work as they would on *nix systems in this release, because this 
pkg-config was compiled with the --enable-indirect-deps option.  This 
option is necessary to properly link dependent DLLs on MSWin/cygwin, but 
means that no library dependency is truly private.  However, .pc files 
that use the .private options will work properly -- as defined on the 
MSWin/cygwin platform: private libs will be folded into the public libs 
list, and private requires will likewise be folded into the public 
requires list.


--
Charles Wilson
pkg-config volunteer maintainer for cygwin


To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.


*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:


[EMAIL PROTECTED]

If you need more information on unsubscribing, start reading here:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at the above URL.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

[ANNOUNCEMENT] Updated: inetutils-1.5-3

[cygwin]

I've updated inetutils, based on the upstream 1.5 release.  A short list 
of the changes appears below, but the documentation has been extensively 
revised. I urge you to read /usr/share/doc/Cygwin/inetutils-1.5.README. 
The old README, from inetutils-1.3.2-40, is now located in 
/usr/share/doc/inetutils-1.5/inetutils.OLD-README.


All clients and servers appear to work, even on Vista, with the possible 
exception of talkd (see inetutils-1.5.README).


NOTE: server names have changed. You may need to update your inetd.conf 
or xinetd.conf files: in.telnetd --> telnetd, etc.


Known issues:

* talkd (possibly just firewall issues) -- see README
* password-less rsh/rcp operation on Vista requires login-1.9-8, which
  is still in test: status as of 2008-04-24. Normal (password required)
  operation works as expected with login-1.9-7.
* anonymous ftp has not been tested
* rexec does not honor ~/.netrc. This is a possible issue in
  cygwin's rcmd() implementation).  rexec does honor $REXEC_USER
  and $REXEC_PASS.
* uucpd has not been tested


Building this package requires a patched cygport:
  http://cygwin.com/ml/cygwin-apps/2008-03/msg00139.html


Major changes with respect to current 1.3.2-40

* new maintainer
* updated to upstream 1.5 release; forward ported all applicable
  cygwin modifications from 1.3.2-40.
* switched to cygport build framework
* servers are now called "ftpd" instead of "in.ftpd". Update your
  inetd / xinetd configuration scripts.
* inetd now supports both inetd.conf and inetd.d/ configuration
  directories.
* inetd --install-as-service is DEPRECATED. If you have installed
  inetd as a service "under its own power" -- that is, without using
  cygrunsrv -- please convert to using either cygrunsrv
$ inetd --remove-as-service
$ iu-config
  or run inetd as a slave of the sysvinit package's init service (see
  inetutils-1.5.README)
* Added support for parsing DOS-style paths in tftpd, recieved
  from tftp clients. (The tftpd command-line arguments must be
  in unix form, as always).
* disabled all services in the default inetd.conf
* updated default motd
* imported security fix for rshd (and rexecd) from 1.3.2-40 release
* now uses the csih package to assist with service installation.
* Added a new option to inetd: -T/--traditional-daemon, which forces
  normal unix-style fork/daemonize behavior.  This is used with the
  (also provided) sysvinit-style startup script, so that inetd can
  be run under the control of the sysvinit package's init daemon.
  So now, there are THREE ways to run inetd as a service:
 a) install as a service using cygrunsrv (with the -D option)
 b) installed as a service under its own power [DEPRECATED]
 c) as a slave to the init service, using /etc/rc.d/init.d/inetd
(which uses the -T option when invoking inetd)
* There's also a little test program for the built-in services, provided
  as source code in /usr/share/doc/inetutils-*/.  You can easily test
  TCP services using:
 telnet  
  but there's no easy way to test UDP services. udp_client can be used
  to do this:
 udp_client   "some data to send"
  For instance, the UDP echo service can be tested using:
 $ udp_client localhost echo "hello"
 Received from localhost: 'hello'.
 $

Upstream changes from inetutils-1.3.2 to 1.5

inetutils-1.5 (2006-10-21)
---
* Various bugs fixes and clean ups.
* inetd
   + New option --environment enables passing client/server
 data via environment variables.
   + New option --resolve enables resolving IP addresses
 before passing them via environment.
   + Allows numeric port names as service names
   + inetd now creates a PID file
* rcp now supports the -V option
* rshd/rexecd now switches to the users home directory
  after authentication.
* rlogin now supports XON/XOFF without needing -8.
* syslogd now can actually disable forwarding.
* talk allows the use of 8-bit ASCII.
* telnet not subject to certain DNS spoofing techniques
  that could possibly foil Kerberos authentication.

inetutils-1.4.2 (2002-12-22)
---
* Fix endianess problem in ftpd.
* Various portability updates.
* Security fix for rexecd/rshd.
* Fix processing accumulated messages in syslogd

inetutils-1.4.1 (2002-09-02)
---
* Fixes a build problem on Solaris
* rsh now honours -V as well as --version
* Fixed a security problem with rshd where new files
  were being created as uid 0.
* Fixed improper ping initialization.
* The syntax of syslog.conf file has been extended.
  The new wildcard facility specification, **, catches
  all messages with a facility not specified explicitely
  in the configuration file.

inetutils-1.4.0 (2002-07-31)
---
* It is now possible to specify whether to compile
  individual utilities us

Re: Install cygwin in Win2K as nonadmin from CD make from WinXP

[Paul Domaskis]

Thorsten Kampe  wrote:
> * Paul Domaskis (Tue, 22 Apr 2008 16:47:16 -0400) wrote:
>>
>> I will be using a standalone Win2K machine on which I will likely
>> not have admin access.  Will this be a problem, if I choose to
>> install only for the account of interest?
>
> No, I use that version exclusively on my machines (because I run
> Cygwin from my USB stick).

Wow.  That's cool.  For any one machine, I guess you must ensure that
the stick maps to the same letter drive whenever you plug it in,
right?  (I'm guessing this because the path is specified in the user's
Windows path).

>> There are various web references to the requirement for admin, but
>> they are generally associated with specific packages e.g. OpenSSH.
>
> Yes, and specific setups (like runnning the sshd as a service)

Yes, that was in fact what I had in mind.

>> I will be creating the installation CD from a WinXP machine. Will
>> the installation CD be OS-agnostic and thus be suitable for a Win2K
>> target machine?
>
> Yes.

Thanks, Thorsten.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: [ANNOUNCEMENT] NEW: libtool-2.2.2-2 / Updated: libltdl7-2.2.2-2

[Yaakov (Cygwin Ports)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Chuck,

Here's yet another interesting case with libtool-2.2:

/bin/sh ../../libtool --tag=CXX --mode=link g++  -O2 -pipe-o
libfoo-1.2.la -rpath /usr/lib -no-undefined sources.lo
libtool: link: rm -fr  .libs/libfoo-1.2.dll.a .libs/libfoo-1.2.la
.libs/libfoo-1.2.lai
libtool: link: g++ -shared -nostdlib   .libs/sources.o
- -L/usr/lib/gcc/i686-pc-cygwin/3.4.4
- -L/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../.. -lstdc++ -lgcc -lcygwin
- -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc -o
.libs/cygfoo-1.2-0.dll -Wl,--enable-auto-image-base -Xlinker
- --out-implib -Xlinker .libs/libfoo-1.2.dll.a
Creating library file: .libs/libfoo-1.2.dll.a
libtool: link: ar cru .libs/libfoo-1.2.  sources.o
libtool: link: ranlib .libs/libfoo-1.2.
libtool: link: ( cd ".libs" && rm -f "libfoo-1.2.la" && ln -s
"../libfoo-1.2.la" "libfoo-1.2.la" )

In this specific case, the static library is missing the ".a" extension
(Windows ignores the final dot, as usual).  Here's why:

This package had AM_GNU_GETTEXT in configure.ac without any arguments
nor AM_GNU_GETTEXT_VERSION.  autoreconf decided "not using Gettext"[1]
and didn't install config.rpath[2].  But AC_LIB_RPATH (from the included
gettext-0.11.2 lib-link.m4) was called; while nothing happened due to
the missing config.rpath, it then defined libext=$acl_cv_libext, which
had never been defined.  This empty $libext clobbered that of libtool.

In this case, the solution was simply to call AM_GNU_GETTEXT_VERSION.
But this is the second case where libtool's had its variables clobbered
by other parts of configure.  Could something be done to make sure that
that can't happen?


Yaakov


[1] autoreconf decided "not using Gettext" because it looks solely for
AM_GNU_GETTEXT_VERSION to make that determination.  (It only looks for
AM_GNU_GETTEXT to see if one of these two is used without the other, and
emits a warning if so.)

[2] lib-link.m4 0.15 adds a line telling automake >= 1.10 that
config.rpath is required, but this package was using 1.9.  In any case,
this macro was from 0.11.2, which preceded automake-1.10.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkgRC2sACgkQpiWmPGlmQSPDkwCfdkU3rN1Ul1YYm6yhebClVyDg
Eu0AoO+O803peOIDxLD4RFEKNIWRHvyi
=mGuQ
-END PGP SIGNATURE-

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Looking for basic documentation on Cygwin and Serial Ports

[Nefastor]

Brian Dessent wrote:
> 
> Nefastor wrote:
> 
>> (...) I don't know which of Cygwin's /dev/tty device corresponds to which
>> serial
>> port on my PC (that is, I only know the COM port number). I can "sort of
>> guess" /dev/tty0 is COM1, but that's a guess, and I'd prefer some
>> certainty.
> 
> Cygwin works the same as Linux, /dev/ttyS0 is the first serial device,
> /dev/ttyS1 is the second, etc.  Please consult the users guide:
> .
> 
> 

That I have, Brian. What itches me is that I'm facing some kind of special
case : My machine has two serial port, one on the MoBo and a USB-serial
adapter, yet Windows calls them COM1 and COM3. I've searched the whole
Device Manager but couldn't find any device that would be COM2. And I can
rename COM1 to COM2.

Speaking of Windows' DM, it's rather quirky on the serial ports : I noticed
that if I unplug my USB cable (COM3) and try to change the name of COM1, in
the drop down box COM3 is listed as "in use" :confused: %-|.

So, I have a machine with two serial ports but no COM2, AND I can change the
COM port number to whatever I want, plus Windows seems to have a bad case of
"phantom limb syndrome". Getting back to your answer : how can know for sure
what Cygwin calls "the first port", or "the second port" ?

Trial and error is obviously not what I'm after, rather I need a way for my
program to know for sure what port it's dealing with. To help me write that
program I'd need to know :

- is there a fixed relationship between COM port number "X" and dev/ttyS
number "Y", such as Y = X - 1 ? For instance, if I change my COM port number
from 3 to 7, will the dev/ttyS number go from 2 to 6, or will it remain
unchanged ?

- if it remains unchanged, I'm assuming Cygwin does some sort of port
enumeration : is that process deterministic ?

Additionally, can you point me to documentation on how to retrieve device /
driver info from my program ? That way, worst case scenario, I can have the
program look for the correct port on its own.

Thank you for your time, I know I'm asking for a lot of stuff but I've got
the feeling the answers would be useful to many.:-)

Nefastor
-- 
View this message in context: 
http://www.nabble.com/Looking-for-basic-documentation-on-Cygwin-and-Serial-Ports-tp16827997p16853883.html
Sent from the Cygwin list mailing list archive at Nabble.com.


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Updated: git-1.5.5.1-1

[Christopher Faylor]

On Thu, Apr 24, 2008 at 01:41:42PM -0700, Matt Seitz (matseitz) wrote:
>> When compiled out of the box, the upstream git maintainers 
>> cater to older cygwin releases, and intentionally disable 
>> certain features that have been reported on their mailing 
>> list, even though they work with the latest cygwin.  
>> Therefore, this build turns those features back on.
>
>What is the easiest way for me to 
>
>1.  find the differences between the upstream git source and the Cygwin git 
>source
>2.  apply those changes to an older build of git
>
>I'd like to try building git 1.5.0.7, with the Cygwin git features turned back 
>on.

I'd suggest downloading and inspecting the git source packages.

You can see a listing of same here: 
http://cygwin.com/packages/git/git-1.5.5.1-1-src
and that should provide some tantalizing clues.

cgf

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Installing Shark library using Cygwin causes [EMAIL PROTECTED] error

[Christopher Faylor]

On Thu, Apr 24, 2008 at 05:32:26PM +0200, Math?us Muzalewski wrote:
> Dear community,
>
> I tried to install the Shark library for machine learning from 
> http://shark-project.sourceforge.net/ on my windows system using cygwin.
> As known from Linux, I called 'autoconfig' and './configure' to create the 
> Makefile and then 'make libs' to build the library.
> Unfortunately it causes an error 'undefined reference to [EMAIL PROTECTED]' 
> and 
> do not build the static library.
> I don't want to create an executably so there is no main() probably at all.
> Can someone maybe try to install Shark on his or her windows computer using 
> cygwin or give me a hint how to fix the problem?

Is there some reason why you're asking us and not asking the people who
would presumably have specific knowledge about shark at
shark-project.sourceforge.net?

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

RE: Updated: git-1.5.5.1-1

[Matt Seitz (matseitz)]

> When compiled out of the box, the upstream git maintainers 
> cater to older cygwin releases, and intentionally disable 
> certain features that have been reported on their mailing 
> list, even though they work with the latest cygwin.  
> Therefore, this build turns those features back on.

What is the easiest way for me to 

1.  find the differences between the upstream git source and the Cygwin git 
source
2.  apply those changes to an older build of git

I'd like to try building git 1.5.0.7, with the Cygwin git features turned back 
on.

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: ls / rm etc return "no such file or directory"

[Tom Hall]

On Thu, Aug 09, 2007 at 01:50:59PM -0700, TomL wrote:
> 
> Based on the idea that its a file locking problem, I ran "handle" from
> sysinternals, and it showed up as an open filehandle in an explorer.exe
> process.  I terminated the process, and all is well.
> 
> I don't understand how it got into that state yet, but I'm closer.  Thanks
> for the hints.

You're a lifesaver !

I get these a lot - sometimes several times a day with vim swap files.

It happens when I run vim over an SSH or telnet session and the session
crashes. After that vim gives me its warning whenever I try to edit that
file until I delete swap file, which I can't.

The only advice I could find was to reboot (which is pretty good advice for
running Windows) which gets annoying on bad network days.

Now I can run 'handle', then 'ps', cross ref the PID from cygwin to windows,
and kill vim - much preferable to a reboot.

Thanks.
Tom 

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Installing Shark library using Cygwin causes [EMAIL PROTECTED] error

[Mathäus Muzalewski]

Dear community,

I tried to install the Shark library for machine learning from 
http://shark-project.sourceforge.net/ on my windows system using cygwin.
As known from Linux, I called 'autoconfig' and './configure' to create 
the Makefile and then 'make libs' to build the library.
Unfortunately it causes an error 'undefined reference to [EMAIL PROTECTED]' 
and do not build the static library.

I don't want to create an executably so there is no main() probably at all.
Can someone maybe try to install Shark on his or her windows computer 
using cygwin or give me a hint how to fix the problem?



Thank you!

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

1.5.25: Segmentation fault on Window, x64, running on VMware

[Christoph Jeksa]

This is a problem in using of Cygwin-tools on Windows x64, running on VMware.

I'm using Cygwin 1.5.25 on a Windows 2003 Server, 64-bit Standard Edition 
running on VMware Workstation ACE Edition, Version 6.0.2. The host system is a 
Windows 2003 Server R2 Enterprise x64 Edition, SP2, running on Intel Xeon CPU 
Dual Quad Processor X5355, 32 GB Memory.

In that environment, different Cygwin-tools (grep, mkdir, etc.) break 
OCCASIONALLY with the state "Segmentation fault (core dumped)". Please find 
below the test case to reproduce the error state:

$ while mkdir foo; rmdir foo; do
>   :
> done

During my tests, the while-loop ran a while and has broken with the error 
message: 
13 [main] rmdir 2364 _cygtls::handle_exceptions: Error while dumping state 
(probably corrupted stack)
Segmentation fault (core dumped)

In an another trial I've got an another errors:
mkdir: cannot create directory `foo': File exists
 10 [main] mkdir 780 _cygtls::handle_exceptions: Error while dumping state 
(probably corrupted stack)
Segmentation fault (core dumped)
rmdir: failed to remove `foo': No such file or directory

... and so on.

Below, the stack dumps from the last trial:

mkdir.exe.stackdump:

Exception: STATUS_ACCESS_VIOLATION at eip=0207
eax=0002 ebx=61168990 ecx= edx=61168990 esi=00F8 edi=0022C900
ebp=0022C858 esp=0022C848 program=C:\cygwin\bin\mkdir.exe, pid 780, thread main
cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame Function  Args
0022C858  0207  (0022C900, 00F8, 0002, 0022C970)
0022C888  610840C7  (0022C900, 0001, 0001, 61168990)
0022C8B8  610844AD  (, , 6110941C, 7D61C92D)
0022CCE8  61096FE4  (, 0400, , )
0022CD98  6100552E  (, 0022CDD0, 61005450, 0022CDD0)
61005450  61004416  (009C, A02404C7, E8611021, FF48)
 10 [main] mkdir 780 _cygtls::handle_exceptions: Error while dumping state 
(probably corrupted stack)

rmdir.exe.stackdump:

Exception: STATUS_ACCESS_VIOLATION at eip=0207
eax=0002 ebx=61168990 ecx= edx=61168990 esi=00F8 edi=0022C900
ebp=0022C858 esp=0022C848 program=C:\cygwin\bin\rmdir.exe, pid 2364, thread main
cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame Function  Args
0022C858  0207  (0022C900, 00F8, 0002, 0022C970)
0022C888  610840C7  (0022C900, 0001, 0001, 61168990)
0022C8B8  610844AD  (, , 6110941C, 7D61C92D)
0022CCE8  61096FE4  (, 0400, , )
0022CD98  6100552E  (, 0022CDD0, 61005450, 0022CDD0)
61005450  61004416  (009C, A02404C7, E8611021, FF48)
 13 [main] rmdir 2364 _cygtls::handle_exceptions: Error while dumping state 
(probably corrupted stack)

the same version of Cygwin and Cygwin-tools works fine, when running on a 
"normal" (physical) x64 Windows system.

Thanks,
--
Christoph


cygcheck.out
Description: cygcheck.out
--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Install cygwin in Win2K as nonadmin from CD make from WinXP

[Thorsten Kampe]

* Paul Domaskis (Tue, 22 Apr 2008 16:47:16 -0400)
> I will be using a standalone Win2K machine on which I will likely not
> have admin access.  Will this be a problem, if I choose to install
> only for the account of interest?

No, I use that version exclusively on my machines (because I run Cygwin 
from my USB stick).

> There are various web references to the requirement for admin, but
> they are generally associated with specific packages e.g. OpenSSH.

Yes, and specific setups (like runnning the sshd as a service)
 
> I will be creating the installation CD from a WinXP machine. Will the
> installation CD be OS-agnostic and thus be suitable for a Win2K target
> machine?

Yes.

Thorsten


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/