Re: Updated: setup.exe (Release 2.864)

[Vasiliy]

Re: Updated: setup.exe (Release 2.867)
Re: Updated: gcc-4.9.2-2 (x86/x86_64)


Dear Cygwin Team,

i) I refer to [1], more recently to [2]:

"The most visible effect is that Setup will now never downgrade a package."

It downgrades the "gcc" package from 4.9.2-2 to 4.9.2-1 right now [3].

ii) Would it be convenient for you to update also the "mingw"
package(s) from current version 4.8.3 to more recent 4.9.2 the same
way you have done it for "gcc"?

Kind regards,
Vasiliy

[1] https://www.cygwin.com/ml/cygwin-announce/2015-02/msg8.html
"Updated: setup.exe (Release 2.864)"

[2] https://www.cygwin.com/ml/cygwin-announce/2015-02/msg00013.html
"Updated: setup.exe (Release 2.867)"

[3] https://www.cygwin.com/ml/cygwin-announce/2015-02/msg6.html
"Updated: gcc-4.9.2-2 (x86/x86_64)"

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

Cygwin64: urlfetch causes SEGFAULT

[Vasiliy]

git clone git://github.com/ifduyue/urlfetch.git
cd urlfetch
python setup.py install
*or*
python3 setup.py install

causes Segmentation fault (also visible in Python 3, if installed
"manually": import urlfetch)

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

Cygwin64: mkshortcut - Segmentation fault

[Vasiliy]

Original suspect:

user@host /etc/postinstall
$ cat /etc/postinstall/xinit.sh
/usr/bin/mkdir -p "$(/usr/bin/cygpath $CYGWINFORALL -P)/Cygwin-X"
/usr/bin/mkshortcut $CYGWINFORALL -P -i /usr/bin/XWin.exe -n
"Cygwin-X/XWin Server" -a "/usr/bin/bash.exe -l -c
/usr/bin/startxwin.exe" /usr/bin/run.exe

user@host /etc/postinstall
$ env V=2 VERBOSE=2 xinit.sh
./xinit.sh: line 2: 22136 Aborted (core dumped)
/usr/bin/mkshortcut $CYGWINFORALL -P -i /usr/bin/XWin.exe -n
"Cygwin-X/XWin Server" -a "/usr/bin/bash.exe -l -c
/usr/bin/startxwin.exe" /usr/bin/run.exe

Real cause:

user@host /etc/postinstall
$ /usr/bin/mkdir -p "$(/usr/bin/cygpath $CYGWINFORALL -P)/Cygwin-X"

user@host /etc/postinstall
$ /usr/bin/mkshortcut $CYGWINFORALL -P -i /usr/bin/XWin.exe -n
"Cygwin-X/XWin Server" -a "/usr/bin/bash.exe -l -c
/usr/bin/startxwin.exe" /usr/bin/run.exe
Aborted (core dumped)

$ cygcheck -f /usr/bin/mkshortcut.exe
cygutils-1.4.12-1

$ /bin/tar -C/ -jxvf cygutils-1.4.12-2.tar.bz2
usr/bin/cygstart.exe
usr/bin/mkshortcut.exe
usr/bin/readshortcut.exe
usr/share/man/man1/cygstart.1.gz
usr/share/man/man1/mkshortcut.1.gz
usr/share/man/man1/readshortcut.1.gz

???:
$ cygcheck -f /usr/bin/mkshortcut.exe
cygutils-1.4.12-1

$ /usr/bin/mkdir -p "$(/usr/bin/cygpath $CYGWINFORALL -P)/Cygwin-X"

$ /usr/bin/mkshortcut $CYGWINFORALL -P -i /usr/bin/XWin.exe -n
"Cygwin-X/XWin Server" -a "/usr/bin/bash.exe -l -c
/usr/bin/startxwin.exe" /usr/bin/run.exe
  4 [main] mkshortcut (9880) C:\cygwin64\bin\mkshortcut.exe: ***
fatal error - cygheap base mismatch detected - 0x0/0x61272950.
This problem is probably due to using incompatible versions of the cygwin DLL.
Search for cygwin1.dll using the Windows Start->Find/Search facility
and delete all but the most recent version.  The most recent version *should*
reside in x:\cygwin\bin, where 'x' is the drive on which you have
installed the cygwin distribution.  Rebooting is also suggested if you
are unable to find another cygwin DLL.
Segmentation fault

$ uname -a
CYGWIN_NT-6.1 Luminous 1.7.20(0.266/5/3) 2013-06-06 17:36 x86_64 Cygwin

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

Fwd: Cygwin64: mkshortcut - Segmentation fault

[Vasiliy]

Please, check/note:
> libcygicons.dll.a < is being *installed* to /usr/lib from the sources instead 
> of > libicons.dll.a < compiled (!)

Best,
Vasiliy


-- Forwarded message ------
From: Vasiliy
Date: Fri, Jun 7, 2013 at 2:35 PM
Subject: Cygwin64: mkshortcut - Segmentation fault
To: cygwin dot cygwin com

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

Fwd: Cygwin64: mkshortcut - Segmentation fault

[Vasiliy]

I vote for this issue be double-checked:

1) there is only one (the latest one provided by setup) cygwin1.dll in my $PATH:
$ which cygwin1.dll
/usr/bin/cygwin1.dll

$ uname -a
CYGWIN_NT-6.1 Luminous 1.7.20(0.266/5/3) 2013-06-06 17:36 x86_64 Cygwin

and rebaseall is not (has not been) designed for a 64bit installation
(both system and Cygwin are 64-bit)

2) provided in (the latest by setup) cygutils 1.4.12-2 mkshortcut.exe
was, in fact, compled with a mismatched version of cygwin1.dll

3) cygport all from the cygutils 1.4.12-2 sources installs, indeed,
libcygicons.dll.a, as opposed to the correct spelling: libicons.dll.a

Please, indeed, take a look at the content you've just attached:

Attachment: cygutils-extra.txt
Description: Text document
...
/usr/bin/cygicons-0.dll
...
/usr/lib/libcygicons.dll.a
/usr/lib/libcygicons.la

and check the content of "libcygicons.la" (should be "libicons.la" as well)

Best,
Vasiliy


-- Forwarded message --
From: Charles Wilson 
To: The Cygwin Mailing List 
Date: Fri, 07 Jun 2013 09:59:03 -0400
Subject: Re: Fwd: Cygwin64: mkshortcut - Segmentation fault
References: 
 

I have no idea what this means. The contents of cygutils,
cygutils-extra, cygutils-x11 are as attached.

--
Chuck



-- Forwarded message --
From: Charles Wilson 
To: The Cygwin Mailing List 
Date: Fri, 07 Jun 2013 09:56:08 -0400
Subject: Re: Cygwin64: mkshortcut - Segmentation fault
References: 

Unfortunately, this is not a problem, per se, within mkshortcut
itself. It's a system issue; make sure there are no other
cygwin1.dll's on your system or in your $PATH. Finally, you could try
manually running rebaseall in your 64bit installation, and then
rebooting.

--
Chuck


-- Forwarded message --
From: Vasiliy
Date: Fri, Jun 7, 2013 at 3:33 PM
Subject: Fwd: Cygwin64: mkshortcut - Segmentation fault
To: cygwin


Please, check/note:
> libcygicons.dll.a < is being *installed* to /usr/lib from the sources instead 
> of > libicons.dll.a < compiled (!)

Best,
Vasiliy


------ Forwarded message --
From: Vasiliy
Date: Fri, Jun 7, 2013 at 2:35 PM
Subject: Cygwin64: mkshortcut - Segmentation fault
To: cygwin

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

chown --recursive [OWNER][:[GROUP]] ... doesn't work

[Vasiliy]

chown --recursive  *.* doesn't change ownership for all files,
single files are proceeded ok

$ uname -srvm
CYGWIN_NT-6.1 1.7.20(0.266/5/3) 2013-06-06 17:36 x86_64

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

x86_64-pc-cygwin-windres.exe vs. cygwin1.dll v1.17.20 version mismatch

[Vasiliy]

 45 [main] x86_64-pc-cygwin-windres (24560)
C:\cygwin\bin\x86_64-pc-cygwin-windres.exe: *** fatal error - cygheap
base mismatch detected - 0x0/0x61272950.
This problem is probably due to using incompatible versions of the cygwin DLL.
Search for cygwin1.dll using the Windows Start->Find/Search facility
and delete all but the most recent version.  The most recent version *should*
reside in x:\cygwin\bin, where 'x' is the drive on which you have
installed the cygwin distribution.  Rebooting is also suggested if you
are unable to find another cygwin DLL.



-- Forwarded message --
From: Vasiliy
Date: Sat, Jun 8, 2013 at 5:47 PM
Subject: chown --recursive [OWNER][:[GROUP]] ... doesn't work
To: cygwin


chown --recursive  *.* doesn't change ownership for all files,
single files are proceeded ok

$ uname -srvm
CYGWIN_NT-6.1 1.7.20(0.266/5/3) 2013-06-06 17:36 x86_64

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

Fwd: x86_64-pc-cygwin-windres.exe vs. cygwin1.dll v1.17.20 version mismatch

[Vasiliy]

Sorry, my fault, please ignore this one.

C:\cygwin\bin\...
needed to be
C:\cygwin64\bin\...

-- Forwarded message --
From: Vasiliy
Date: Sat, Jun 8, 2013 at 9:56 PM
Subject: x86_64-pc-cygwin-windres.exe vs. cygwin1.dll v1.17.20 version mismatch
To: cygwin


 45 [main] x86_64-pc-cygwin-windres (24560)
C:\cygwin\bin\x86_64-pc-cygwin-windres.exe: *** fatal error - cygheap
base mismatch detected - 0x0/0x61272950.
This problem is probably due to using incompatible versions of the cygwin DLL.
Search for cygwin1.dll using the Windows Start->Find/Search facility
and delete all but the most recent version.  The most recent version *should*
reside in x:\cygwin\bin, where 'x' is the drive on which you have
installed the cygwin distribution.  Rebooting is also suggested if you
are unable to find another cygwin DLL.

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

xorg-server no longer support -wgl option

[Vasiliy]

I have compiled 'gnubik' from GNU Ftp, and it fails with:

$ gnubik
(gnubik:28564): GdkGLExt-WARNING **: Window system doesn't support OpenGL.


Upon checking, I couldn't see any longer XWin's -wgl option working,
though no warnings were issued. Is that all right?:

$ uname -srvm
CYGWIN_NT-6.1 1.7.20(0.266/5/3) 2013-06-06 17:36 x86_64

user@host ~
$ XWin.exe -multiwindow -wgl
Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.14.1.0
OS: CYGWIN_NT-6.1 Luminous 1.7.20(0.266/5/3) 2013-06-06 17:36 x86_64
OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601](Win64)
Package: version 1.14.1-1 built 2013-05-07

XWin was started with the following command line:

XWin -multiwindow -wgl

(II) xorg.conf is not supported
(II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information
LoadPreferences: /Users/Khalak/.XWinrc not found
LoadPreferences: Loading /etc/X11/system.XWinrc
LoadPreferences: Done parsing the configuration file...
winDetectSupportedEngines - DirectDraw installed, allowing ShadowDD
winDetectSupportedEngines - Windows NT, allowing PrimaryDD
winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowDDNL
winDetectSupportedEngines - Returning, supported engines 001f
winSetEngine - Multi Window or Rootless => ShadowGDI
winScreenInit - Using Windows display depth of 32 bits per pixel
winAllocateFBShadowGDI - Creating DIB with width: 1366 height: 768 depth: 32
winFinishScreenInitFB - Masks: 00ff ff00 00ff
winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32
winInitMultiWindowWM - Calling pthread_mutex_lock ()
winMultiWindowXMsgProc - Calling pthread_mutex_lock ()
Initializing built-in extension Generic Event Extension
Initializing built-in extension SHAPE
Initializing built-in extension MIT-SHM
Initializing built-in extension XInputExtension
Initializing built-in extension XTEST
Initializing built-in extension BIG-REQUESTS
Initializing built-in extension SYNC
Initializing built-in extension XKEYBOARD
Initializing built-in extension XC-MISC
Initializing built-in extension XINERAMA
Initializing built-in extension XFIXES
Initializing built-in extension XFree86-Bigfont
Initializing built-in extension RENDER
Initializing built-in extension RANDR
Initializing built-in extension COMPOSITE
Initializing built-in extension DAMAGE
Initializing built-in extension MIT-SCREEN-SAVER
Initializing built-in extension DOUBLE-BUFFER
Initializing built-in extension RECORD
Initializing built-in extension DPMS
Initializing built-in extension X-Resource
MIT-SHM extension disabled due to lack of kernel support
XFree86-Bigfont extension local-client optimization disabled due to
lack of shared memory support in the kernel
[dix] Could not init font path element /usr/share/fonts/TTF/, removing
from list!
[dix] Could not init font path element /usr/share/fonts/OTF/, removing
from list!
winPointerWarpCursor - Discarding first warp: 683 384
(--) 5 mouse buttons found
(--) Setting autorepeat to delay=500, rate=31
(--) Windows keyboard layout: "0409" (0409) "US", type 7
(--) Found matching XKB configuration "English (USA)"
(--) Model = "pc105" Layout = "us" Variant = "none" Options = "none"
Rules = "base" Model = "pc105" Layout = "us" Variant = "none" Options = "none"
winBlockHandler - pthread_mutex_unlock()
winInitMultiWindowWM - pthread_mutex_lock () returned.
winInitMultiWindowWM - pthread_mutex_unlock () returned.
winMultiWindowXMsgProc - pthread_mutex_lock () returned.
winInitMultiWindowWM - DISPLAY=:0.0
winMultiWindowXMsgProc - pthread_mutex_unlock () returned.
winProcEstablishConnection - winInitClipboard returned.
winMultiWindowXMsgProc - DISPLAY=:0.0
winClipboardProc - DISPLAY=:0.0
winInitMultiWindowWM - XOpenDisplay () returned and successfully
opened the display.
winMultiWindowXMsgProc - XOpenDisplay () returned and successfully
opened the display.
winClipboardProc - XOpenDisplay () returned and successfully opened the display.

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

Re: __cygwin_environ, __imp_environ, _cur_environ, where is 'environ' symbol?

[Vasiliy]

ok, it seems that newlib/libc/stdlib/environ.c has not made its way
into cygwin1.dll and/or libcygwin.a; shouldn't that be included?

From: Corinna Vinschen 
To: cygwin at cygwin dot com
Date: Wed, 12 Jun 2013 11:53:15 +0200
Subject: Re: __cygwin_environ, __imp_environ, _cur_environ, where is
'environ' symbol?
References: 
Reply-to: cygwin at cygwin dot com



environ is the exported symbol referencing the internal __cygwin_environ
variable on x86_64.  Linking against and accessing it works for me:

  $ uname -a
  CYGWIN_NT-6.2 VMBERT864 1.7.21(0.266/5/3) 2013-06-11 21:43 x86_64 Cygwin
  $ cat > envtest.c <

  int
  main ()
  {
extern char **environ;

printf ("environ: %p first entry: <%s>\n", &environ, environ[0]);
return 0;
  }
  EOF
  $ gcc -o envtest envtest.c
  $ ./envtest
  environ: 0x1802a4778 first entry: 


Corinna

--
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat

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

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

[Feature request] Setup64.exe should respect more recent packages' version

[Vasiliy]

Could it be possible for Setup64.exe that it would not offer
downgrading packages by default if their more recent counterparts are
installed? Example of an undesirable behavior: installed is bash 4.2,
but 4.1 version is wrongly suggested, etc.

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

Fwd: [Feature request] Setup64.exe should respect more recent packages' version

[Vasiliy]

Ok, I understand, and, yes, it's also about setup.exe. That would be
true if the package was marked as 'a test package', aka those marked
'[test]' in setup.ini, but what if they were not? From my example bash
4.2 is not marked as [test] (I've changed 'installed.db' file
accordingly), yet setup(64) downgrades it to 4.1

Why not use two conditions instead of just one? Say, 'if package is
more recent, and not marked as [test], then do not downgrade (keep)'.

___
From: "Larry Hall (Cygwin)" 
To: cygwin at cygwin dot com
Date: Mon, 17 Jun 2013 15:01:37 -0400
Subject: Re: [Feature request] Setup64.exe should respect more recent
packages' version
References: 
Reply-to: cygwin at cygwin dot com



On 6/17/2013 2:54 PM, Vasiliy wrote:

Could it be possible for Setup64.exe that it would not offer
downgrading packages by default if their more recent counterparts are
installed? Example of an undesirable behavior: installed is bash 4.2,
but 4.1 version is wrongly suggested, etc.

Setup suggests downgrading only when you've install a test package.
There's nothing distinctive about 'setup.64.exe' vs 'setup.exe' in
this regard.

--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

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

Re: Fwd: [Feature request] Setup64.exe should respect more recent packages' version

[Vasiliy]

On 6/17/2013, Larry wrote:

That is the way it works for non-test packages.

I'm not sure what mirror you're using but on mirror.mcs.anl.gov, bash
4.1.11 is the only version available for x64.

~~~

No, it does not.

I've compiled, and installed bash 4.2.45 for x64, and made appropriate
changes in the /etc directory, so, it is up on the list of the
installed packages. However, it keeps downgrading.

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

x86_64-w64-mingw32: wdm.h conflicting types with winnt.h

[Vasiliy]

Please, take a look at:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/ddk/ntddk.h (why '/mingw/'?)

which has:
#include 

which in turn causes a lot of conflicting types errors with winnt.h,
besides complaining wdm.h is not being found

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

no output from GNUTLS package

[Vasiliy]

Hello,

I could not get any output from 'gnutls' Cygwin64 package. Could
somebody invoke it as follows:

gnutls-cli - GnuTLS client

or any other example.

Compiled from the sources it passes many tests, but still no luck,
very strange, indeed.

Thank you in advance.
Best regards,

Vasiliy

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

test-driver: line 95: Segmentation fault

[Vasiliy]

Help needed: whenever I run 'make check' I'm experiencing the same
kind or error:
copying 'test-driver' from... to... upon (auto)configure phase, then,
when checking:
test-driver: line 95:  Segmentation fault

It's likely due to some mis-compiled binary on my system. How to track it down?

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

Fwd: no output from GNUTLS package

[Vasiliy]

Thank you, Csaba,

I was able to track down a stranded library which shouldn't be there,
and now it works!

I've also tracked down that problem with 'test-driver'. Look at that:

$ gdb --args /usr/bin/sh /usr/share/automake-1.14/test-driver
GNU gdb (GDB) 7.6.50.20130320-cvs
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-cygwin".
For bug reporting instructions, please see:
...
Reading symbols from /usr/bin/sh...Reading symbols from
/usr/lib/debug/usr/bin/sh.exe.dbg...done.
done.
(gdb) run
Starting program: /usr/bin/sh /usr/share/automake-1.14/test-driver
[New Thread 9900.0xc10]
[New Thread 9900.0x1bec]
[New Thread 9900.0xe38]
/usr/share/automake-1.14/test-driver: line 95: $log_file: ambiguous redirect
FAIL:
/usr/share/automake-1.14/test-driver: line 114: $trs_file: ambiguous redirect
/usr/share/automake-1.14/test-driver: line 115: $trs_file: ambiguous redirect
/usr/share/automake-1.14/test-driver: line 116: $trs_file: ambiguous redirect
/usr/share/automake-1.14/test-driver: line 117: $trs_file: ambiguous redirect
[Inferior 1 (process 9900) exited with code 01]
(gdb) quit

$ gdb --args /usr/bin/sh /usr/share/automake-1.14/test-driver --log-file=/tmp
GNU gdb (GDB) 7.6.50.20130320-cvs
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-cygwin".
For bug reporting instructions, please see:
...
Reading symbols from /usr/bin/sh...Reading symbols from
/usr/lib/debug/usr/bin/sh.exe.dbg...done.
done.
(gdb) run
Starting program: /usr/bin/sh /usr/share/automake-1.14/test-driver
--log-file=/tmp
[New Thread 2164.0x164c]
[New Thread 2164.0x24a4]
[New Thread 2164.0x2550]
/usr/share/automake-1.14/test-driver: invalid option: '--log-file=/tmp'
[New Thread 2164.0x19d4]
Usage:
  test-driver --test-name=NAME --log-file=PATH --trs-file=PATH
  [--expect-failure={yes|no}] [--color-tests={yes|no}]
  [--enable-hard-errors={yes|no}] [--] TEST-SCRIPT
The '--test-name', '--log-file' and '--trs-file' options are mandatory.

So, there is a problem with 'test-driver' either because a testsuite
does not provide --test-name=NAME or because --log-file=/tmp or
--log-file=/tmp/delme is wrongly considered an invalid option. It
applies to automake 1.13 as well.

Could a Cygwin Team suggest if we could change that behavior,
particularly, make omitting --test-name not so critical?

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

basename: a faulty warning 'extra operand --test-name' in tests causes test-driver to fail

[Vasiliy]

Hello,

When trying to 'make check' Open MPI from the SVN sources I observe
the following issue with 'basename' from 'coreutils' Cygwin package:

basename: extra operand `--test-name'
Try `basename --help' for more information.
--> Testing
test-driver: line 95:   Aborted (core dumped)
"$@" > $log_file 2>&1

and upon investigating:
$ /usr/share/automake-1.14/test-driver --help
Usage:
  test-driver --test-name=NAME --log-file=PATH --trs-file=PATH
  [--expect-failure={yes|no}] [--color-tests={yes|no}]
  [--enable-hard-errors={yes|no}] [--] TEST-SCRIPT
The '--test-name', '--log-file' and '--trs-file' options are mandatory.

make  check-TESTS
make[1]: Entering directory
'/usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/build/test/asm'
make[2]: Entering directory
'/usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/build/test/asm'
basename: extra operand `--test-name'
Try `basename --help' for more information.
--> Testing
basename: extra operand `--test-name'
Try `basename --help' for more information.
--> Testing
basename: extra operand `--test-name'
Try `basename --help' for more information.
--> Testing
basename: extra operand `--test-name'
Try `basename --help' for more information.
--> Testing
 ...

/usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/config/test-driver:
line 95:   Segmentation fault  (core dumped) "$@" > $log_file
2>&1


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

Re: basename: a faulty warning 'extra operand --test-name' in tests causes test-driver to fail

[Vasiliy]

Marco, you're right, it's the problem in their 'run_tests' file, I've
got baffled due to a lack of time. However, there's likely an issue
with Automake not recognizing '--log-file' option, but it's another
story.


> On Fri, 12 Jul 2013 18:18:06 +0200 marco atzeri wrote:
>
> basename has no testname options. So I do not understand why
> it should be a basename problem...
>
> specially as it is the same on linux
> http://linux.die.net/man/1/basename
>
> not clear to me what is aborting
> could you clarify ?
>
> Regards
> Marco

On Fri, Jul 12, 2013 at 5:25 PM, Vasiliy  wrote:
> Hello,
>
> When trying to 'make check' Open MPI from the SVN sources I observe
> the following issue with 'basename' from 'coreutils' Cygwin package:
>
> basename: extra operand `--test-name'
> Try `basename --help' for more information.
> --> Testing
> test-driver: line 95:   Aborted (core dumped)
> "$@" > $log_file 2>&1
>
> and upon investigating:
> $ /usr/share/automake-1.14/test-driver --help
> Usage:
>   test-driver --test-name=NAME --log-file=PATH --trs-file=PATH
>   [--expect-failure={yes|no}] [--color-tests={yes|no}]
>   [--enable-hard-errors={yes|no}] [--] TEST-SCRIPT
> The '--test-name', '--log-file' and '--trs-file' options are mandatory.
> 
> make  check-TESTS
> make[1]: Entering directory
> '/usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/build/test/asm'
> make[2]: Entering directory
> '/usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/build/test/asm'
> basename: extra operand `--test-name'
> Try `basename --help' for more information.
> --> Testing
> basename: extra operand `--test-name'
> Try `basename --help' for more information.
> --> Testing
> basename: extra operand `--test-name'
> Try `basename --help' for more information.
> --> Testing
> basename: extra operand `--test-name'
> Try `basename --help' for more information.
> --> Testing
>  ...
>
> /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/config/test-driver:
> line 95:   Segmentation fault  (core dumped) "$@" > $log_file
> 2>&1
> 

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

Re: basename: a faulty warning 'extra operand --test-name' in tests causes test-driver to fail

[Vasiliy]

Sorry. Please read as: "However, there's likely an issue
with Automake's 'test-driver' not recognizing '--log-file' option."

BZW, it was obvious from my first post that I've made a typo.

On Fri, 12 Jul 2013 15:26:15 -0400 Christopher Faylor wrote:
>
>> On Fri, Jul 12, 2013 at 09:21:40PM +0200, Vasiliy wrote:
>> Marco, you're right, it's the problem in their 'run_tests' file, I've
>> got baffled due to a lack of time. However, there's likely an issue
>> with Automake not recognizing '--log-file' option, but it's another
>> story.
>
> automake doesn't have a --log-file option.  I can't really imagine what
> it would do.

On Fri, Jul 12, 2013 at 9:21 PM, Vasiliy  wrote:
> Marco, you're right, it's the problem in their 'run_tests' file, I've
> got baffled due to a lack of time. However, there's likely an issue
> with Automake not recognizing '--log-file' option, but it's another
> story.
>
>
>> On Fri, 12 Jul 2013 18:18:06 +0200 marco atzeri wrote:
>>
>> basename has no testname options. So I do not understand why
>> it should be a basename problem...
>>
>> specially as it is the same on linux
>> http://linux.die.net/man/1/basename
>>
>> not clear to me what is aborting
>> could you clarify ?
>>
>> Regards
>> Marco
>
> On Fri, Jul 12, 2013 at 5:25 PM, Vasiliy  wrote:
>> Hello,
>>
>> When trying to 'make check' Open MPI from the SVN sources I observe
>> the following issue with 'basename' from 'coreutils' Cygwin package:
>>
>> basename: extra operand `--test-name'
>> Try `basename --help' for more information.
>> --> Testing
>> test-driver: line 95:   Aborted (core dumped)
>> "$@" > $log_file 2>&1
>>
>> and upon investigating:
>> $ /usr/share/automake-1.14/test-driver --help
>> Usage:
>>   test-driver --test-name=NAME --log-file=PATH --trs-file=PATH
>>   [--expect-failure={yes|no}] [--color-tests={yes|no}]
>>   [--enable-hard-errors={yes|no}] [--] TEST-SCRIPT
>> The '--test-name', '--log-file' and '--trs-file' options are mandatory.
>> 
>> make  check-TESTS
>> make[1]: Entering directory
>> '/usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/build/test/asm'
>> make[2]: Entering directory
>> '/usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/build/test/asm'
>> basename: extra operand `--test-name'
>> Try `basename --help' for more information.
>> --> Testing
>> basename: extra operand `--test-name'
>> Try `basename --help' for more information.
>> --> Testing
>> basename: extra operand `--test-name'
>> Try `basename --help' for more information.
>> --> Testing
>> basename: extra operand `--test-name'
>> Try `basename --help' for more information.
>> --> Testing
>>  ...
>>
>> /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/config/test-driver:
>> line 95:   Segmentation fault  (core dumped) "$@" > $log_file
>> 2>&1
>> 

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

Re: basename: a faulty warning 'extra operand --test-name' in tests causes test-driver to fail

[Vasiliy]

I'm happy to provide you with an update on 'extra operand --test-name'
occasionally being fed to 'basename' by some testsuites, which was
fixed by Automake maintainers:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14840

On Fri, Jul 12, 2013 at 11:19 PM, Vasiliy  wrote:

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