[ANNOUNCEMENT] Updated: texlive-20150521-3, texlive-collection-basic-20150617-3

[Ken Brown]

The following packages have been updated in the Cygwin distribution:

* texlive-20150521-3
* libkpathsea6-20150521-3
* libkpathsea-devel-20150521-3
* libptexenc1-20150521-3
* libptexenc-devel-20150521-3
* libsync1-20150521-3
* libsync-devel-20150521-3
* libtexlua52_5-20150521-3
* libtexlua52-devel-20150521-3
* libtexluajit2-20150521-3
* libtexluajit-devel-20150521-3
* texlive-collection-basic-20150617-3

TeX Live provides a comprehensive, cross-platform TeX system. It 
includes all the major TeX-related programs, macro packages, and fonts 
that are free software, including support for many languages around the 
world. For more information, see


  http://www.tug.org/texlive/

This update is primarily a rebuild of the TeX Live binaries to remove 
the dependence on the obsolete libicu55.  I've also taken the 
opportunity to make two minor changes:


1. I've applied an upstream patch to fix a bug involving euptex 
(http://tug.org/pipermail/tex-live/2015-September/037378.html).


2. I've moved the fontconfig configuration file for the TeX Live fonts 
from /etc/conf.avail (now deprecated) to /usr/share/fontconfig/conf.avail.


This means that users who have previously run the 
/usr/bin/texlive-enable-fontconfig script will have to re-run it.  See 
/usr/share/doc/texlive/README.Cygwin for more information about this script.


Ken Brown
Cygwin's TeX Live maintainer

--
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: icu-56.1-1

[Ken Brown]

The following packages have been updated in the Cygwin distribution:

* libicu56-56.1-1
* libicu-devel-56.1-1
* icu-doc-56.1-1

libicu55 is now obsolete.  Package maintainers, please rebuild any 
packages that depend on it when you get a chance.


ICU is a mature, widely used set of C/C++ and Java libraries providing 
Unicode and Globalization support for software applications.  ICU is 
widely portable and gives applications the same results on all platforms 
and between C/C++ and Java software.


This is an update to the latest upstream release.

Ken Brown
Cygwin's ICU maintainer

--
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: how can I disable the warning about X11 forwarding

[Peter]

On 08.10.2015 20:56, Andrey Repin wrote:

Greetings, Peter!


I want to allow some users to run an interactive program on my w2012
server via ssh.
The program is a console app so I do not need X forwarding.
Users are connecting via putty without an X server.
Alas they always get nagged with the
"WARNING: No xauth data; using fake authentication data for X11 forwarding."
Is there a way to get rid of this message?

Tell them to not request X11 forwarding, and they won't be nagged by it.



I don't understand this answer.
The command is justssh  user@hostwhen I get the warning.
If the command was  ssh -X user@host  or ssh -Y user@host  it would be 
clear to me.

So maybe there is some default in sshd_config that should be changed?


--
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: how can I disable the warning about X11 forwarding

[Andrey Repin]

Greetings, Peter!

> I want to allow some users to run an interactive program on my w2012 
> server via ssh.
> The program is a console app so I do not need X forwarding.
> Users are connecting via putty without an X server.
> Alas they always get nagged with the
> "WARNING: No xauth data; using fake authentication data for X11 forwarding."
> Is there a way to get rid of this message?

Tell them to not request X11 forwarding, and they won't be nagged by it.


-- 
With best regards,
Andrey Repin
Thursday, October 8, 2015 21:55:52

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 error

[Douglas Coup]

I encountered this after I upgraded my workstation to either Windows 8 
or Windows 8.1, I don't remember which.


The problem went away when I upgraded to the latest and greatest Cygwin.

Objective Systems, Inc.
REAL WORLD ASN.1 AND XML SOLUTIONS
Tel: +1 (484) 875-9841
Fax: +1 (484) 875-9830
Toll-free: (877) 307-6855 (USA only)
http://www.obj-sys.com

On 10/8/2015 1:07 PM, Dalton Lange wrote:
I attempted to use the gcc command to find out if it were working, and 
it gave me this error:



G:\Homework\Week 2>gcc
  0 [main] gcc 12776 find_fast_cwd: WARNING: Couldn't compute 
FAST_CWD pointer.  Please report this problem to

the public mailing list cygwin@cygwin.com
gcc: no input files

G:\Homework\Week 2>




I should mention:
I am on a flash drive,
I have tried using the full gcc command,
I have put cygwin in the path.

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

Cygwin error

[Dalton Lange]

I attempted to use the gcc command to find out if it were working, and 
it gave me this error:



G:\Homework\Week 2>gcc
  0 [main] gcc 12776 find_fast_cwd: WARNING: Couldn't compute 
FAST_CWD pointer.  Please report this problem to

the public mailing list cygwin@cygwin.com
gcc: no input files

G:\Homework\Week 2>




I should mention:
I am on a flash drive,
I have tried using the full gcc command,
I have put cygwin in the path.

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

how can I disable the warning about X11 forwarding

[Peter]

I want to allow some users to run an interactive program on my w2012 
server via ssh.

The program is a console app so I do not need X forwarding.
Users are connecting via putty without an X server.
Alas they always get nagged with the
"WARNING: No xauth data; using fake authentication data for X11 forwarding."
Is there a way to get rid of this message?



--
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: libjpeg-turbo-1.4.2-1

[Yaakov Selkowitz]

The following packages have been updated in the Cygwin distribution:

* libjpeg8-1.4.2-1
* libjpeg-devel-1.4.2-1
* libturbojpeg0-1.4.2-1
* libturbojpeg-devel-1.4.2-1
* jpeg-1.4.2-1

libjpeg-turbo is a derivative of libjpeg that uses SIMD instructions
(MMX, SSE2, NEON) to accelerate baseline JPEG compression and
decompression on x86, x86-64, and ARM systems.  On such systems,
libjpeg-turbo is generally 2-4x as fast as the unmodified version of
libjpeg, all else being equal.

This is an update to the latest upstream release.

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

Re: fstat st_size on open files on Parallels filesystem is wrong

[Jonathan Lennox]

Hi, following up on this issue from last year.  The message I'm replying to
is at .

The problem is weird behavior in Parallels Desktop-hosted Windows VMs, when
accessing the host's native Mac OS X filesystem.  See the thread for the
details.

On Wednesday, April 23 2014, "Corinna Vinschen" wrote to "cygwin@cygwin.com" 
saying:

> > At this point this is looking pretty clearly like a Parallels Tools bug.
> > I'll report it to them.
> 
> Yes, that sounds good.  Given that, I'm wondering if we should try to
> workaround this problem at all or rather wait to see if the vendor will
> fix the issue.

No such luck, despite two major version revisions of Parallels Desktop (I'm
now on version 11.0.2) and moving to Windows 10 as the guest OS -- the bug
perists, unchanged.  So it looks like Cygwin will need to add a workaround
for this filesystem to fix the problem.

The output of /usr/lib/csih/getVolInfo seems to be unchanged from the output
I reported last year.

> Thanks.  This looks pretty much like a filesystem pretending to be
> FAT-like.  There may be another problem lurking, which is, are the inode
> numbers (called "FileId" or "IndexNumber" in Windows) persistant?  With
> FAT this is not the case, and given the above, it might be a problem...
> 
> ...or not.  I just realize that Cygwin doesn't even try to use the
> FileId as inode number on filesystems with FILE_PERSISTENT_ACLS==FALSE
> so, never mind.
> 
> OTOH, does it support hardlinks?  If so, two hardlinks to the
> same file would have different inode numbers on Cygwin.

How would I figure these points out?

-- 
Jonathan Lennox
len...@cs.columbia.edu

--
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: Running a program using a DLL under Cygwin

[Andrey Repin]

Greetings, Yucong Sun!

https://cygwin.com/acronyms/#TOFU pretty please...

> I think symlink is a cygwin thing.  Windows won't find that DLL (just
> like you won't find it using windows explorer.)

Unless he have created a Windows symlink, that is correct.
Explorer, however, may find it, as Cygwin symlinks are Windows LNK files.

> Windows only support loading DLL from project directory, or  system32
> as far as I know.

That's not correct. Windows can be told to load DLL's from multiple places,
and you can add to that by registering your DLL in AppPaths registry key.

But a bottom point of the issue is that the OP's project is poorly designed
and needs a rework in the part of finding and loading custom plugins
(I suppose).

There should be no need to move DLL's around, least to place them in a shared
location like user's ~/bin...


-- 
With best regards,
Andrey Repin
Thursday, October 8, 2015 18:08:16

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: Problem with nm in binutils-2.25-2 on x86

[Ken Brown]

On 10/8/2015 5:35 AM, JonY wrote:

On 10/7/2015 17:57, JonY wrote:

On 10/6/2015 21:12, Ken Brown wrote:

This is a followup to
https://www.cygwin.com/ml/cygwin/2015-10/msg00059.html .

I tried to build icu using gcc-5 and binutils-2.25-2 on x86.  The build
appeared to hang when cygport was stripping executables.  I traced the
problem to a call to 'nm -l' in src_postinst.cygpart.  This produced
errors like the following when called on some of the DLLs:

$ nm -l cygicui18n56.dll
6270c458 b .bssBFD: Dwarf Error: Could not find abbrev number 1151.
6270c594 b .bssBFD: Dwarf Error: Could not find abbrev number 1151.
6270c0cc b .bssBFD: Dwarf Error: Could not find abbrev number 1151.
...

This particular DLL can be found at

   http://sanibeltranquility.com/cygwin/cygicui18n56.dll.xz



Hi Ken,

Are you able to reproduce a test case? Seems to require some complexity
to trigger it.


Actually, it turns out to be quite easy to trigger it.  I just tested 
random programs that were sitting around, and here's the smallest one I 
found that exhibited the problem:


$ cat getcwd.c
#include 
#include 

int
main ()
{
  char buf[PATH_MAX];
  getcwd (buf, PATH_MAX);
}

$ gcc getcwd.c

$ nm -l a.exe
00406000 b .bssBFD: Dwarf Error: Could not find abbrev number 120.
00406018 b .bssBFD: Dwarf Error: Could not find abbrev number 120.
[...]
00406040 b _u.25303BFD: Dwarf Error: Could not find abbrev number 120.
00401000 T _WinMainCRTStartup 
/usr/src/debug/cygwin-2.2.1-1/winsup/cygwin/crt0.c:23

004070b8 i fthunkBFD: Dwarf Error: Could not find abbrev number 120.
00407074 i hnameBFD: Dwarf Error: Could not find abbrev number 120.

Ken

--
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: Running a program using a DLL under Cygwin

[Csaba Raduly]

Hi,

On Thu, Oct 8, 2015 at 3:56 PM, Yucong Sun  wrote:

Please don't top-post (https://cygwin.com/acronyms/#TOFU)

> I think symlink is a cygwin thing.  Windows won't find that DLL (just
> like you won't find it using windows explorer.)
>
> Windows only support loading DLL from project directory, or  system32
> as far as I know.

There are rather more possibilities, listed here:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx

1. The directory from which the application loaded.
2. The current directory.
3. The system directory. Use the GetSystemDirectory function to get
the path of this directory.
4. The 16-bit system directory. There is no function that obtains the
path of this directory, but it is searched.
5. The Windows directory. Use the GetWindowsDirectory function to get
the path of this directory.
6. The directories that are listed in the PATH environment variable.
Note that this does not include the per-application path specified by
the App Paths registry key. The App Paths key is not used when
computing the DLL search path.

If SafeDllSearchMode is enabled, the current directory is demoted from
#2 to #5 (just before the PATH search).

There's also SetDllDirectory (
https://msdn.microsoft.com/en-us/library/windows/desktop/ms686203%28v=vs.85%29.aspx
)

>
> On Thu, Oct 8, 2015 at 9:37 PM, Dr Rainer Woitok
>  wrote:
>> Greetings,
>>
>> I'm running  a program which requires a DLL  sitting in my "~/bin/" dir-
>> ectory.  Since "~/bin/" is contained  in my "PATH" environment variable,
>> everything works  as desired.   Recently I moved  the DLL elsewhere, re-
>> placing it with a symbolic link in "~/bin/".  This caused the program to
>> fail to locate the DLL.  Moving the DLL back in place caused the program
>> to work again.
>>
>> Is this a Windows problem  (since DLLs are Windows  rather than Unix) or
>> Cygwin's?   The link was created with the normal  "ln -s" command.  And,
>> if that matters, Cygwin is running on Vista here.

If the CYGWIN environment containswinsymlinks:native
(https://cygwin.com/cygwin-ug-net/using.html#pathnames-symlinks) ,
Cygwin creates symlinks that Windows can understand. I don't know
whether Windows will load a DLL if a native symlink to the DLL is in
the PATH (or any other directories in the search list).

Csaba
-- 
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
The Tao of math: The numbers you can count are not the real numbers.
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds

--
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: Running a program using a DLL under Cygwin

[Yucong Sun]

I think symlink is a cygwin thing.  Windows won't find that DLL (just
like you won't find it using windows explorer.)

Windows only support loading DLL from project directory, or  system32
as far as I know.

On Thu, Oct 8, 2015 at 9:37 PM, Dr Rainer Woitok
 wrote:
> Greetings,
>
> I'm running  a program which requires a DLL  sitting in my "~/bin/" dir-
> ectory.  Since "~/bin/" is contained  in my "PATH" environment variable,
> everything works  as desired.   Recently I moved  the DLL elsewhere, re-
> placing it with a symbolic link in "~/bin/".  This caused the program to
> fail to locate the DLL.  Moving the DLL back in place caused the program
> to work again.
>
> Is this a Windows problem  (since DLLs are Windows  rather than Unix) or
> Cygwin's?   The link was created with the normal  "ln -s" command.  And,
> if that matters, Cygwin is running on Vista here.
>
> Sincerely,
>   Rainer
>
> PS: Please also reply  to me personally,  as I'm not  subscribed to this
> list.
>
> --
> 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

Running a program using a DLL under Cygwin

[Dr Rainer Woitok]

Greetings,

I'm running  a program which requires a DLL  sitting in my "~/bin/" dir-
ectory.  Since "~/bin/" is contained  in my "PATH" environment variable,
everything works  as desired.   Recently I moved  the DLL elsewhere, re-
placing it with a symbolic link in "~/bin/".  This caused the program to
fail to locate the DLL.  Moving the DLL back in place caused the program
to work again.

Is this a Windows problem  (since DLLs are Windows  rather than Unix) or
Cygwin's?   The link was created with the normal  "ln -s" command.  And,
if that matters, Cygwin is running on Vista here.

Sincerely,
  Rainer

PS: Please also reply  to me personally,  as I'm not  subscribed to this
list.

--
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: Problem with nm in binutils-2.25-2 on x86

[JonY]

On 10/7/2015 17:57, JonY wrote:
> On 10/6/2015 21:12, Ken Brown wrote:
>> This is a followup to
>> https://www.cygwin.com/ml/cygwin/2015-10/msg00059.html .
>>
>> I tried to build icu using gcc-5 and binutils-2.25-2 on x86.  The build
>> appeared to hang when cygport was stripping executables.  I traced the
>> problem to a call to 'nm -l' in src_postinst.cygpart.  This produced
>> errors like the following when called on some of the DLLs:
>>
>> $ nm -l cygicui18n56.dll
>> 6270c458 b .bssBFD: Dwarf Error: Could not find abbrev number 1151.
>> 6270c594 b .bssBFD: Dwarf Error: Could not find abbrev number 1151.
>> 6270c0cc b .bssBFD: Dwarf Error: Could not find abbrev number 1151.
>> ...
>>
>> This particular DLL can be found at
>>
>>   http://sanibeltranquility.com/cygwin/cygicui18n56.dll.xz
>>

Hi Ken,

Are you able to reproduce a test case? Seems to require some complexity
to trigger it.





signature.asc
Description: OpenPGP digital signature