Re: Updated: gcc-5.2.0-1 (Test x86/x86_64)

2015-10-01 Thread cyg Simple 
On 9/30/2015 7:36 PM, David Stacey wrote:
> On 30/09/15 23:34, JonY wrote:
>> On 10/1/2015 00:05, David Stacey wrote:
>>> On 30/09/15 12:15, JonY wrote:
 gcc-5.2.0-1 has been uploaded for 32bit and 64bit Cygwin.

 This is the first series of the 5.x releases, and should be considered
 as experimental as such.
>>>
>>> Have you managed to work around the ABI change in gcc-5 [1], or will
>>> this require a mass rebuild at the point gcc-5 becomes 'current'?
>>>
>>> [1] -http://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/
>> As far as I know, every gcc release will break C++ ABI, so it would mean
>> rebuilding everything C++.
> 
> According to the Red Hat blog above, the last time g++ caused an ABI
> change was back in the 3.x days, so it hasn't happened for a while. Ah
> well, we have maintainers for most packages in Cygwin, so we'll have to
> co-ordinate a rebuild.

Regardless, JonY is correct.  Every C++ release, regardless of the
vendor, causes an ABI break with shared libraries and the naming of the
object elements (mangled names).  It is the nature created by technical
reason.  Not to mention that the first paragraph of the release states
that there is an ABI break.  And then there is this paragraph: "So the
plan for this ABI change has been to leave the soname (and the existing
binary interface) alone, and express the new ABI using different mangled
names."

-- 
cyg 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

Re: Why does robocopy confuse input and output files defined with Cygwin/bash and perl?

2015-10-01 Thread cyg Simple 
On 9/30/2015 3:27 PM, Andrey Repin wrote:
> Greetings, Eliot Moss!
> 
>> Dealing with "odd" characters like \ and such can be a pain, huh?
>> Perhaps it will help you to know that bash will expand variables
>> inside double-quoted arguments, i.e., "${src}".  (You can write
>> "$src" if you want, but over the years I am finding it clearer /
>> better to use the { } to make clear the name of the variable I
>> want expanded.)
> 
>> Also, you may find the cygpath utility helpful, and the $( ) idiom
>> of bash.
> 
> It isn't "idiom of bash", it is a POSIX construction.
> 
>> Thus:
> 
>> robocopy /s "$(cygpath -w /cygdrive/c/Users/siegfriend/Documents/bin)" 
>> "$(cygpath -w
>> /cygdrive/f/backup/unison/bin)"
> 
>> I believe this will do what you want.  cygpath can be very helpful
>> hen you desire to run a Windows program from the cygwin environment.
> 
> I would suggest cygpath -m.

Not for robocopy, it is likely not to survive / instead of \.  I would
prefix it with "cmd /c" though or perhaps create a bash script called
robocopy to do the path conversion before calling the Windows
robocopy.exe.  That way the command line looks typical.

-- 
cyg 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

Re: using rsync with Win32/UNC pathnames?

2015-10-01 Thread gregoria 
I am using a software called *Long Path Tool* for such errors and it is
working like charm, i have no problems in copying, Win32/UNC pathnames or
extracting anything anywhere.



--
View this message in context: 
http://cygwin.1069669.n5.nabble.com/using-rsync-with-Win32-UNC-pathnames-tp34501p121625.html
Sent from the Cygwin list mailing list archive at Nabble.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

Re: [Cygwin-ports-general] Ncview

2015-10-01 Thread Yaakov Selkowitz 
On Mon, 2015-09-28 at 17:33 +0200, Marco Atzeri wrote:
> On 28/09/2015 16:07, Vasileios Anagnostopoulos wrote:
> > is it possible to include ncview
> > (http://meteora.ucsd.edu/~pierce/ncview_home_page.html) in the software
> > distribution?
> 
> 1) wrong mailing lists, the right one is cygwin (at) cygwin (dot) com
> please follow up there.
> 
> >
> > For me the installation was only a ./configure && make && make install
> 
> 2) the 64 bit crashes inside X libs.
> I never succeeded to identify the root cause

Confirmed.  Often 64-bit-only issues come down to one or more of the
following:

* implicit function declarations.  Per the C standard, argument types
are assumed to match whatever is given (which may be wrong if e.g. 0 is
used instead of 0L or (PointerType)0 or NULL etc.) and the return type
is assumed to be int (which will truncate the actual return value when
it is actually a long/pointer).

* vararg types.  Because these types aren't declared, the compiler can't
automatically cast values to the correct type, so literal values and
symbolic constants must be explicitly cast if they are not meant to be
an int and are not obviously a long/pointer.

In the case of ncview, I strongly suspect the latter should anyone be
interested in fixing this.

--
Yaakov



--
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

New C compilation error using the Openwindow/xview-devel toolkit on current (September 2015) 32 bit Cygwin

2015-10-01 Thread Paul Morgan 
I can no longer compile C code linked to the Openwindows/xview-devel
toolkit using gcc in Cygwin 32 bits, installed on Windows 7 32 or 64
bit systems. I run setup-x86 weekly to update Cygwin - compilation ran
fine in August 2015 but by mid September 2015 it was failing on the
same code.

I can reproduce this by compiling C code from the xview-examples
package (from e.g., Debian i386
https://packages.debian.org/jessie/xview-examples ), to eliminate any
issues with my specific code. For example,

$ cd usr/share/doc/xviewg/examples/panels

$ cc -O -I/usr/openwin/include simple_panel.c -L/usr/openwin/lib
-lxview -lolgx -lX11 -o simple_panel

In file included from /usr/openwin/include/xview/pkg.h:27:0,
 from /usr/openwin/include/xview/pkg_public.h:19,
 from /usr/openwin/include/xview/generic.h:39,
 from /usr/openwin/include/xview/xview_xvin.h:41,
 from /usr/openwin/include/xview/xview.h:18,
 from simple_panel.c:5:
/usr/openwin/include/xview/notify.h:34:13: error: conflicting types
for ‘ucontext_t’
 typedef int ucontext_t;
 ^
In file included from /usr/include/sys/signal.h:357:0,
 from /usr/include/signal.h:5,
 from /usr/openwin/include/xview/xview_xvin.h:18,
 from /usr/openwin/include/xview/xview.h:18,
 from simple_panel.c:5:
/usr/include/sys/ucontext.h:24:3: note: previous declaration of
‘ucontext_t’ was here
 } ucontext_t;
   ^

There now appears to be an issue with the definition of ucontext_t in
xview-devel with respect to Cygwin. If I manually edit
/usr/openwin/include/xview/base.h and change line 70 from undef to
#define SYSV_UCONTEXT
... the example above then compiles fine.

I cannot find any reference to recent Cygwin updates related to the
definition of ucontext_t - and I may be fixing a symptom of something
else rather than the underlying cause. Any suggestions?

Thanks

Paul


cygcheck.out
Description: Binary data
--
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: New C compilation error using the Openwindow/xview-devel toolkit on current (September 2015) 32 bit Cygwin

2015-10-01 Thread Ken Brown 

On 10/1/2015 2:38 PM, Paul Morgan wrote:

I can no longer compile C code linked to the Openwindows/xview-devel
toolkit using gcc in Cygwin 32 bits, installed on Windows 7 32 or 64
bit systems. I run setup-x86 weekly to update Cygwin - compilation ran
fine in August 2015 but by mid September 2015 it was failing on the
same code.

I can reproduce this by compiling C code from the xview-examples
package (from e.g., Debian i386
https://packages.debian.org/jessie/xview-examples ), to eliminate any
issues with my specific code. For example,

$ cd usr/share/doc/xviewg/examples/panels

$ cc -O -I/usr/openwin/include simple_panel.c -L/usr/openwin/lib
-lxview -lolgx -lX11 -o simple_panel

In file included from /usr/openwin/include/xview/pkg.h:27:0,
  from /usr/openwin/include/xview/pkg_public.h:19,
  from /usr/openwin/include/xview/generic.h:39,
  from /usr/openwin/include/xview/xview_xvin.h:41,
  from /usr/openwin/include/xview/xview.h:18,
  from simple_panel.c:5:
/usr/openwin/include/xview/notify.h:34:13: error: conflicting types
for ‘ucontext_t’
  typedef int ucontext_t;
  ^
In file included from /usr/include/sys/signal.h:357:0,
  from /usr/include/signal.h:5,
  from /usr/openwin/include/xview/xview_xvin.h:18,
  from /usr/openwin/include/xview/xview.h:18,
  from simple_panel.c:5:
/usr/include/sys/ucontext.h:24:3: note: previous declaration of
‘ucontext_t’ was here
  } ucontext_t;
^

There now appears to be an issue with the definition of ucontext_t in
xview-devel with respect to Cygwin. If I manually edit
/usr/openwin/include/xview/base.h and change line 70 from undef to
#define SYSV_UCONTEXT
... the example above then compiles fine.

I cannot find any reference to recent Cygwin updates related to the
definition of ucontext_t


https://cygwin.com/ml/cygwin-announce/2015-08/msg00033.html

--
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

[ANNOUNCEMENT] Updated: tzcode-2015g-1

2015-10-01 Thread Yaakov Selkowitz 
The following package has been updated in the Cygwin distribution:

* tzcode-2015g-1

The Time Zone Database (often called tz or zoneinfo) contains code and
data that represent the history of local time for many representative
locations around the globe. It is updated periodically to reflect
changes made by political bodies to time zone boundaries, UTC offsets,
and daylight-saving rules.

This is an update to the latest upstream release:

https://mm.icann.org/pipermail/tz-announce/2015-October/34.html

--
Yaakov

--
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

Updated: tzcode-2015g-1

2015-10-01 Thread Yaakov Selkowitz 
The following package has been updated in the Cygwin distribution:

* tzcode-2015g-1

The Time Zone Database (often called tz or zoneinfo) contains code and
data that represent the history of local time for many representative
locations around the globe. It is updated periodically to reflect
changes made by political bodies to time zone boundaries, UTC offsets,
and daylight-saving rules.

This is an update to the latest upstream release:

https://mm.icann.org/pipermail/tz-announce/2015-October/34.html

--
Yaakov

Re: [Cygwin-ports-general] Ncview

2015-10-01 Thread Marco Atzeri 

On 01/10/2015 19:35, Yaakov Selkowitz wrote:

On Mon, 2015-09-28 at 17:33 +0200, Marco Atzeri wrote:

On 28/09/2015 16:07, Vasileios Anagnostopoulos wrote:




2) the 64 bit crashes inside X libs.
 I never succeeded to identify the root cause


Confirmed.  Often 64-bit-only issues come down to one or more of the
following:

* implicit function declarations.  Per the C standard, argument types
are assumed to match whatever is given (which may be wrong if e.g. 0 is
used instead of 0L or (PointerType)0 or NULL etc.) and the return type
is assumed to be int (which will truncate the actual return value when
it is actually a long/pointer).


This is not. The only two implicit declaration are of type int
and declaring them changes noting.



* vararg types.  Because these types aren't declared, the compiler can't
automatically cast values to the correct type, so literal values and
symbolic constants must be explicitly cast if they are not meant to be
an int and are not obviously a long/pointer.


I don't find any case.


In the case of ncview, I strongly suspect the latter should anyone be
interested in fixing this.


The hard issue is that only cygwin 64 bit seems impacted,
while other 64 platform are fine,
and that the crash is well deep X libraries during the
destruction phase of graphical elements

#0  LayoutChild (w=w@entry=0x60065ef80)
at /usr/src/debug/libXaw-1.0.12-2/src/Form.c:693
#1  0x0003cabefc26 in LayoutChild (w=w@entry=0x60064e8a0)
at /usr/src/debug/libXaw-1.0.12-2/src/Form.c:702
#2  0x0003cabefc26 in LayoutChild (w=)
at /usr/src/debug/libXaw-1.0.12-2/src/Form.c:702
#3  0x0003cabf04ed in Layout (fw=0x60011a2e0, width=,
height=, force_relayout=1)
at /usr/src/debug/libXaw-1.0.12-2/src/Form.c:565
#4  0x0003cabefb2b in XawFormChangeManaged (w=0x60011a2e0)
at /usr/src/debug/libXaw-1.0.12-2/src/Form.c:1022
#5  0x0003ca758f5c in XtUnmanageChildren (children=0x22c8d0,
num_children=1) at /usr/src/debug/libXt-1.1.4-2/src/Manage.c:184
#6  0x0003ca759038 in XtUnmanageChild (child=0x60065ef70,
child@entry=0x60064e8a0) at 
/usr/src/debug/libXt-1.1.4-2/src/Manage.c:204

#7  0x0003ca74b1db in XtPhase2Destroy (widget=0x60064e8a0)
at /usr/src/debug/libXt-1.1.4-2/src/Destroy.c:228
#8  0x0003ca74b4e8 in _XtDoPhase2Destroy (app=app@entry=0x60003c030,
dispatch_level=dispatch_level@entry=1)
at /usr/src/debug/libXt-1.1.4-2/src/Destroy.c:322
#9  0x0003ca75018b in XtDispatchEvent (event=0x100632a80 )
at /usr/src/debug/libXt-1.1.4-2/src/Event.c:1432
#10 0x0001004257af in x_process_user_input ()
at /usr/src/debug/ncview-2.1.5-1/src/interface/x_interface.c:2492
#11 0x00010041f75a in in_process_user_input ()
at /usr/src/debug/ncview-2.1.5-1/src/interface/interface.c:149
#12 0x0001004031e5 in process_user_input ()
at /usr/src/debug/ncview-2.1.5-1/src/ncview.c:718
#13 0x0001004012f4 in main (argc=2, argv=0x22cb30)
at /usr/src/debug/ncview-2.1.5-1/src/ncview.c:149

as the X graphics elements are not correctly destroyed in sequence.

If someone more knowledgeable in X is interested I can provide the 
program and a test case.


Regards
Marco

--
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-ports-general] Ncview

2015-10-01 Thread Michael Enright 
On Thu, Oct 1, 2015 at 10:35 AM, Yaakov Selkowitz  wrote:
>
> Confirmed.  Often 64-bit-only issues come down to one or more of the
> following:
>
> * implicit function declarations.  Per the C standard, argument types
> are assumed to match whatever is given (which may be wrong if e.g. 0 is
> used instead of 0L or (PointerType)0 or NULL etc.) and the return type
> is assumed to be int (which will truncate the actual return value when
> it is actually a long/pointer).
>
> * vararg types.  Because these types aren't declared, the compiler can't
> automatically cast values to the correct type, so literal values and
> symbolic constants must be explicitly cast if they are not meant to be
> an int and are not obviously a long/pointer.
>

Good list. I would also add attempting to store pointer differences in
an "int" instead of ptrdiff_t and the issue you can see from
https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models,
which is that the integer types other than long long on 64-bit Windows
are 32-bits while on 64-bit Linux 'long' and 'long long' are both
64-bit. This issue means that 'long' is a good-enough hack for
ptrdiff_t on 64-bit Linux but not 64-bit Windows. Does Cygwin differ
from Windows itself on this issue? Most 32-bit-designed code is
probably more sensitive to the pointer-difference aspect of this.

--
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

ssh with password allows commands that fail with ssh via key

2015-10-01 Thread Blando, Frank (Helion Managed Engineering) 
I suspect this is already answered somewhere, but my googling has not brought 
up an answer.

Environment:
CygWin with OpenSSH 6.6.1p1-3 on Windows 2012 R2. Using the domain 
administrator account as the target on Windows.

Issue:
When I ssh into Windows from Linux, if I use a password, "powershell -command 
get-cluster" works. If I use key (store in .ssh/authorized_keys), "powershell 
-command get-cluster" returns access denied. Simpler commands do not appear to 
make a distinction and work equally well with password or keys.

--
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: ssh with password allows commands that fail with ssh via key

2015-10-01 Thread Andrey Repin 
Greetings, Blando, Frank (Helion Managed Engineering)!

> I suspect this is already answered somewhere, but my googling has not brought 
> up an answer.

> Environment:
> CygWin with OpenSSH 6.6.1p1-3 on Windows 2012 R2. Using the domain
> administrator account as the target on Windows.

> Issue:
> When I ssh into Windows from Linux, if I use a password, "powershell
> -command get-cluster" works. If I use key (store in .ssh/authorized_keys),
> "powershell -command get-cluster" returns access denied. Simpler commands do
> not appear to make a distinction and work equally well with password or keys.

Please read the documentation. It is explicitly explained there in great
detail.
http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview


-- 
With best regards,
Andrey Repin
Friday, October 2, 2015 02:24:20

Sorry for my terrible english...


--
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 bash for loops : repeated errors : [main] bash 1972 fork: child -1 - CreateProcessW failed for errno 9 bash: fork: Bad file descriptor

2015-10-01 Thread Vermessung AVT - Wolfgang Rieger 
Hi Paul,

I also get Bad File Descriptor errors, though in a quite different situation, 
see my recent topic "gawk: Bad File Descriptor error with concurrent readonly 
access to a network file" on Sep 25. There seems to be some issue in some file 
opening process that occurs with parallel processes and eventually concurrent 
file access (as in my case). May be the basic problem behind is similar to 
yours?

Kind regards,
Wolfgang


> After observing for a week on the system with the fix applied, I did not see 
> this issue reoccur.
> I do however still suspect that it is a bug in cygwin, indeed a race 
> condition of some sorts, which probably becomes
> apparent when starting up a process takes (much) longer than expected.
> As said, the guard32.dll is probably scanning the new CreateProcess 
> candidate. I suspect that there's an timing
> assumption in the Cygwin fork code. But as I cannot be sure, I leave it at 
> that.
>
> Regards,
> Paul

RE: ssh with password allows commands that fail with ssh via key

2015-10-01 Thread Blando, Frank (Helion Managed Engineering) 
Thanks you for the pointer. I hope I read this correctly (It is kind of 
overwhelming), and unfortunately, that does not appear to be it.
1 - Unlike the mentioned description, access to network share works fine either 
way (Example command that works either way "powershell -command get-childitem 
\\server\share") - I have enabled CredSSP and I this might be why.
2 - Using passwd -R to register the password did not make the problem go away 
(In the windows tradition I restarted the service and killed all sessions)

Frank Blando
Your English beats my non-existent Russian!
-Original Message-
From: Andrey Repin [mailto:anrdae...@yandex.ru] 
Sent: Thursday, October 1, 2015 5:27 PM
To: Blando, Frank (Helion Managed Engineering) ; 
cygwin@cygwin.com
Subject: Re: ssh with password allows commands that fail with ssh via key

Greetings, Blando, Frank (Helion Managed Engineering)!

> I suspect this is already answered somewhere, but my googling has not brought 
> up an answer.

> Environment:
> CygWin with OpenSSH 6.6.1p1-3 on Windows 2012 R2. Using the domain 
> administrator account as the target on Windows.

> Issue:
> When I ssh into Windows from Linux, if I use a password, "powershell 
> -command get-cluster" works. If I use key (store in 
> .ssh/authorized_keys), "powershell -command get-cluster" returns 
> access denied. Simpler commands do not appear to make a distinction and work 
> equally well with password or keys.

Please read the documentation. It is explicitly explained there in great detail.
http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview


--
With best regards,
Andrey Repin
Friday, October 2, 2015 02:24:20

Sorry for my terrible english...


--
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: [ITP] nccmp 1.7.4.1

2015-10-01 Thread Marco Atzeri 

On 30/09/2015 02:54, Remik Ziemlinski wrote:

This is a command-line diff tool for the NetCDF scientific data file
format.
It's used by labs worldwide and I am the author.



 $ cygport nccmp.cygport check
 does not work.



gcc -DHAVE_CONFIG_H -I. 
-I/pub/tmp/ITP/nccmp-1.7.4.1-1.x86_64/src/nccmp-1.7.4.1/ 
   test -I..  -I../src  -I/include -I/libsrc4 
-ggdb -O2 -pipe -Wimplicit-function-d 
eclaration 
-fdebug-prefix-map=/pub/tmp/ITP/nccmp-1.7.4.1-1.x86_64/build=/usr/src 
/debug/nccmp-1.7.4.1-1 
-fdebug-prefix-map=/pub/tmp/ITP/nccmp-1.7.4.1-1.x86_64/sr 

c/nccmp-1.7.4.1=/usr/src/debug/nccmp-1.7.4.1-1  -MT 
test_nccmp_odometer-test_ncc 
mp_odometer.o -MD -MP -MF 
.deps/test_nccmp_odometer-test_nccmp_odometer.Tpo -c - 
 o test_nccmp_odometer-test_nccmp_odometer.o 
`test -f 'test_nccmp_odometer.c' || 
   echo 
'/pub/tmp/ITP/nccmp-1.7.4.1-1.x86_64/src/nccmp-1.7.4.1/test/'`test_nccmp_od 
  ometer.c
/pub/tmp/ITP/nccmp-1.7.4.1-1.x86_64/src/nccmp-1.7.4.1/test/test_nccmp_odometer.c 
  :2:28: fatal error: 
nccmp_odometer.h: No such file or directory

 #include 
^
compilation terminated.
Makefile:713: recipe for target 
'test_nccmp_odometer-test_nccmp_odometer.o' fail 
   ed

make[2]: *** [test_nccmp_odometer-test_nccmp_odometer.o] Error 1
make[2]: Target 'test_nccmp_odometer.exe' not remade because of errors.
gcc -DHAVE_CONFIG_H -I. 
-I/pub/tmp/ITP/nccmp-1.7.4.1-1.x86_64/src/nccmp-1.7.4.1/ 
   test -I..  -I../src  -I/include -I/libsrc4 
-ggdb -O2 -pipe -Wimplicit-function-d 
eclaration 
-fdebug-prefix-map=/pub/tmp/ITP/nccmp-1.7.4.1-1.x86_64/build=/usr/src 
/debug/nccmp-1.7.4.1-1 
-fdebug-prefix-map=/pub/tmp/ITP/nccmp-1.7.4.1-1.x86_64/sr 

c/nccmp-1.7.4.1=/usr/src/debug/nccmp-1.7.4.1-1  -MT 
test_nccmp_strlist-test_nccm 
p_strlist.o -MD -MP -MF .deps/test_nccmp_strlist-test_nccmp_strlist.Tpo 
-c -o te 
st_nccmp_strlist-test_nccmp_strlist.o `test -f 'test_nccmp_strlist.c' || 
echo '/ 
pub/tmp/ITP/nccmp-1.7.4.1-1.x86_64/src/nccmp-1.7.4.1/test/'`test_nccmp_strlist.c
mv -f .deps/test_nccmp_strlist-test_nccmp_strlist.Tpo 
.deps/test_nccmp_strlist-t 
est_nccmp_strlist.Po
gcc -I/include -I/libsrc4 -ggdb -O2 -pipe 
-Wimplicit-function-declaration -fdebu 

g-prefix-map=/pub/tmp/ITP/nccmp-1.7.4.1-1.x86_64/build=/usr/src/debug/nccmp-1.7. 
  4.1-1 
-fdebug-prefix-map=/pub/tmp/ITP/nccmp-1.7.4.1-1.x86_64/src/nccmp-1.7.4.1=/ 
  usr/src/debug/nccmp-1.7.4.1-1 
   -o test_nccmp_strlist.exe test_nccmp_strlist-te 
  st_nccmp_strlist.o ../src/nccmp-xmalloc.o 
../src/nccmp-nccmp_strlist.o -lnetcdf 
 -lm
gcc -DHAVE_CONFIG_H -I. 
-I/pub/tmp/ITP/nccmp-1.7.4.1-1.x86_64/src/nccmp-1.7.4.1/ 
   test -I..  -I../src  -I/include -I/libsrc4 
-ggdb -O2 -pipe -Wimplicit-function-d 
eclaration 
-fdebug-prefix-map=/pub/tmp/ITP/nccmp-1.7.4.1-1.x86_64/build=/usr/src 
/debug/nccmp-1.7.4.1-1 
-fdebug-prefix-map=/pub/tmp/ITP/nccmp-1.7.4.1-1.x86_64/sr 

c/nccmp-1.7.4.1=/usr/src/debug/nccmp-1.7.4.1-1  -MT 
test_nccmp_user_type-test_nc 
cmp_user_type.o -MD -MP -MF 
.deps/test_nccmp_user_type-test_nccmp_user_type.Tpo 
   -c -o 
test_nccmp_user_type-test_nccmp_user_type.o `test -f 
'test_nccmp_user_type   .c' || 
echo 
'/pub/tmp/ITP/nccmp-1.7.4.1-1.x86_64/src/nccmp-1.7.4.1/test/'`test_n 
   ccmp_user_type.c
/pub/tmp/ITP/nccmp-1.7.4.1-1.x86_64/src/nccmp-1.7.4.1/test/test_nccmp_user_type. 
  c:1:25: fatal error: 
nccmp_error.h: No such file or directory

 #include 
 ^
compilation terminated.
Makefile:741: recipe for target 
'test_nccmp_user_type-test_nccmp_user_type.o' fa 
   iled

make[2]: *** [test_nccmp_user_type-test_nccmp_user_type.o] Error 1
make[2]: Target 'test_nccmp_user_type.exe' not remade because of errors.
make[2]: Leaving directory 
'/cygdrive/e/cyg_pub/tmp/ITP/nccmp-1.7.4.1-1.x86_64/b 
uild/test'