Re: [RFU] monotone-0.40-1

[Corinna Vinschen]

On Apr 23 23:44, Lapo Luchini wrote:
 http://lapo.it/~lapo/cygwin/monotone-0.40-1.tar.bz2
 http://lapo.it/~lapo/cygwin/monotone-0.40-1-src.tar.bz2
 http://lapo.it/~lapo/cygwin/setup.hint

Uploaded.  Thanks.

 PS: this package is the result of 10 hours of compilation under QEMU ;-)

:)
Corinna

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

tcp-wrappers for 1.7.0

[Corinna Vinschen]

Hi Chuck,

would you mind to build a new tcp-wrappers package exclusively for
1.7.0, which has IPv6 enabled?


Thanks in advance,
Corinna

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

minires-devel deleted in release-2

[Corinna Vinschen]

Hi,

since the minires resolver functions are now in Cygwin, there's no
need for the minires package anymore.  Since minires is still needed
for old packages, I didn't remove it from the release-2 area.

However, I deleted minires-devel from release-2.  As a result, I also
removed the minires-devel requirement from the setup.hint files of
ORBit-devel and libclamav-devel.


FYI,
Corinna

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

New openssh/openssl/syslog-ng packages in release-2

[Corinna Vinschen]

Hi,

I though I should open the dance of 1.7-specific packages.

I just uploaded new openssh, openssl and syslog-ng packages to
release-2, which have been built against Cygwin 1.7.0.  That means,
openssh and syslog-ng are now both IPv6-enabled.  Since we don't have a
IPv6-enabled tcp-wrappers right now, I disabled tcp-wrappers support in
OpenSSH as well.

Anyway, please feel free to give these new packages a test.  Especially
people playing with IPv6 ;)


Corinna

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

1.7 packages

[Yaakov (Cygwin Ports)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

There's been a LOT of back and forth over the 1.7 DLL and release
directory.  Could someone (who actually knows what they're talking
about) please outline the *conclusion* of all that discussion, namely:

* where can a list of practical changes between 1.5 and 1.7 be found?
* can 1.7 be installed and/or run in parallel to 1.5, or is a separate
box required?
* how is 1.7 to be installed?
* how are 1.7 packages to be uploaded and organized?
* for how long will maintainers be expected to maintain two sets of
releases?


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

iEYEAREIAAYFAkgQkhMACgkQpiWmPGlmQSMOQQCePqQ608cO1tirx+puv+qBtbNo
t/wAoKLV6VzC7EkqK3atZ2SZfY+Hg3yh
=5aWp
-END PGP SIGNATURE-

Re: 1.7 packages

[Corinna Vinschen]

On Apr 24 08:58, Yaakov (Cygwin Ports) wrote:
 * where can a list of practical changes between 1.5 and 1.7 be found?

http://cygwin.com/ml/cygwin-apps/2008-04/msg00185.html

Missing in this list are a couple of newly exported functions, namely:

- open_memstream, fmemopen, futimens.

- openat, faccessat, fchmodat, fchownat, fstatat, futimesat, linkat,
  mkdirat, mkfifoat, mknodat, readlinkat, renameat, symlinkat, unlinkat,
  utimensat.

 * can 1.7 be installed and/or run in parallel to 1.5, or is a separate
 box required?

In theory, you can do this on a single machine.  Practically, setup
isn't quite up to the task right now.  It still installes mount points
in the registry under the keys used by Cygwin 1.5.x.  That's why I
suggest to use another machine, for instance in a VM.  OTOH, if you
know what you do...

 * how is 1.7 to be installed?

http://cygwin.com/setup-1.7.exe

 * how are 1.7 packages to be uploaded and organized?

Like the 1.5 packages, just in the parallel release-2 area.

 * for how long will maintainers be expected to maintain two sets of
 releases?

Until we are all more or less confident that we can release 1.7 and
its packages to the world.

You don't have to generate new packages if your package doesn't depend
on any of the new features.  Other than that, if your package is IPv6
capable, just not on Cygwin, or if your package is linked against
minires, or if your package uses static buffers of size PATH_MAX, you
should definitely generate new packages.


Corinna

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

Re: RFD: Adding ability for maintainers to upload their own packages

[Lapo Luchini]

Christopher Faylor wrote:

I've been playing with the notion of allowing maintainers to upload
their own packages for some time.  Over the three day weekend, I started
implementing a method that I think will work.
  


Mhh, I kinda lost the end of the discussion: does something automated 
exist already (and to whom should I send my aithorized_keys?) or right 
now the good-old-RFU-messages are still needed?


I've just sent an RFU as I've seen other people do that, but in case 
there's a semi-automated way, I'd love not to disturb the few actual 
uploaders ;-)


--
Lapo Luchini
[EMAIL PROTECTED] (OpenPGP  X.509)
www.lapo.it (Jabber, ICQ, MSN)

Re: 1.7 packages

[Brian Dessent]

Yaakov (Cygwin Ports) wrote:

 * where can a list of practical changes between 1.5 and 1.7 be found?

Probably the best list is:
http://cygwin.com/ml/cygwin-apps/2008-04/msg00185.html.  However,
things are always in flux.

 * can 1.7 be installed and/or run in parallel to 1.5, or is a separate
 box required?
 * how is 1.7 to be installed?

They can't be run in parallel (simultaneously), but they can be
installed in parallel.  1.7 reads the mount table in /etc/fstab, which
means if you keep a 1.7 tree it won't see the mounts of your normal 1.5
tree in the registry.

The current hitch is that the work in setup has not been completed to
compliment this, so it's a little hacky.  To install a 1.7 tree in
parallel to a 1.5 tree, this is the procedure:

1. Stop all 1.5 services and processes.
2. Save and then remove the 1.5 mount table, e.g. mount -m
/bin/mounts.bat; umount -A.  You might also need umount -u -A if you also 
have user mounts, I don't remember if -A removes both system and user.  Make 
sure the mount table is empty before continuing.
3. (Optional) Temporarily rename your 1.5 tree to something else just to
make sure it's not touched by setup, e.g. ren \cygwin \cygwin-foo. 
This shouldn't be strictly necessary if you've ensured the mount table
is empty.
4. Run http://cygwin.com/setup-1.7.exe making sure to select a
new/different root dir for the 1.7 location.
5. (Optional) Rename your 1.5 tree back if you renamed it in 3.
6. Remove the useless registry mounts that setup-1.7 just made and
restore the 1.5 registry mounts by running the mounts.bat created in 2. 
Make sure that this batch file calls the 1.5 mount command, e.g. by
running it in the bin dir of the 1.5 tree.

At this point you should have two working trees: the 1.5 tree with its
mount table in the registry and the 1.7 tree with its mount table in
fstab.  You can verify that everything is setup correctly as running the
1.5 mount command should show the 1.5 tree as root and the 1.7 mount
command should show the 1.7 tree as root.

From this point on you should be able to do any testing you want, as
long as you don't try to have things running from both trees at once. 
Services of course will present a bit of a problem; you'd have to either
install a second copy with a different name or always remove/reinstall
when switching, and of course they shouldn't be used simultaneously.

Once setup has been updated this procedure will be a lot simpler, but
the above should work until then.  You can continue to update the 1.5
tree by using the normal setup.  To update the 1.7 tree you will
unfortunately have to run through the above each time, as setup-1.7 will
still see the 1.5 mount table in the registry, so you have to hide it
first and restore the 1.5 one afterwards.

 * how are 1.7 packages to be uploaded and organized?

As far as I know everything works the same, except that you upload the
files under release-2/.  Everything else should be automatic.

 * for how long will maintainers be expected to maintain two sets of
 releases?

IMHO, only until 1.7 is released.  After that, the 1.5 tree will be left
to grow weeds and drift off into the mists of time.  Of course, if you
feel like releasing updates into the 1.5 tree (e.g. security patches)
I'm sure that would be fine, but I don't think there's any expectation
of service once 1.7 is finally out the door and made current.  But this
is all just MHO, others may have a different view.

Brian

Re: RFD: Adding ability for maintainers to upload their own packages

[Christopher Faylor]

On Thu, Apr 24, 2008 at 04:40:24PM +0200, Lapo Luchini wrote:
 Christopher Faylor wrote:
 I've been playing with the notion of allowing maintainers to upload
 their own packages for some time.  Over the three day weekend, I started
 implementing a method that I think will work.
   

 Mhh, I kinda lost the end of the discussion: does something automated exist 
 already (and to whom should I send my aithorized_keys?) or right now the 
 good-old-RFU-messages are still needed?

 I've just sent an RFU as I've seen other people do that, but in case 
 there's a semi-automated way, I'd love not to disturb the few actual 
 uploaders ;-)

There's no automated way yet but I may have time to work on it next
week.

It will require a valid sshv2 key however so be forewarned.

cgf

Re: tcp-wrappers for 1.7.0

[Charles Wilson]

Corinna Vinschen wrote:

would you mind to build a new tcp-wrappers package exclusively for
1.7.0, which has IPv6 enabled?


Fairly soon. I was hoping that the setup-1.7.exe issues would get 
resolved soon, so that this procedure:

  http://cygwin.com/ml/cygwin-apps/2008-04/msg00299.html
wasn't quite so onerous. But, looks like that won't happen for a while, 
so...


Also, I *had* planned on installing the cygwin-1.7 tree on my vista 
machine, but I've had difficulties with bootstrapping and autotooling on 
Vista+cygwin-1.5: lots of these:


 [main] ? (2152) C:\cygwin\bin\perl.exe: *** fatal error - couldn't 
allocate heap, Win32 error 487, base 0x99, top 0xC7, 
reserve_size 3010560, allocsize 3014656, page_const 4096


even after running rebaseall.  And then STFW, and running 'rebaseall -b 
0x6500' (no joy).


I guess next I should turn of Address Space Layout Randomization, then 
re-run rebaseall. Sigh.


Dare I hope that cygwin-1.7 might be better behaved, or does this have 
absolutely nothing to do with the cygwin1.dll and is all about the 
*other* dll's?


--
Chuck

Not able to download xorg-x11-bin-6.8.99.901-1.tar.bz2

[Jovanovic, Zika]

Hi,


From two mirror sites same problem with downloading
xorg-x11-bin-6.8.99.901-1.tar.bz2 file
During download got a message not completed and out of 132 Kb got max
126 Kb. 
I tried to download the file alone form an ftp site and md5sum is not
the one that should be in setup.exe who is checking the file before
installation.

I guess the md5sum in setup.exe is not correct.

Attaching the output form cygcheck -s -v -r as text attachment

I hope to receive some guideline how to install this particular file or
a fix for distribution to be announced.

Zika


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

src/winsup/cygwin ChangeLog cygwin.din fhandle ...

[corinna]

CVSROOT:/cvs/src
Module name:src
Changes by: [EMAIL PROTECTED]   2008-04-24 09:59:54

Modified files:
winsup/cygwin  : ChangeLog cygwin.din fhandler.cc fhandler.h 
 fhandler_disk_file.cc posix.sgml syscalls.cc 
 times.cc winsup.h 
winsup/cygwin/include/cygwin: version.h 

Log message:
* cygwin.din (futimens): Export.
(utimensat): Export.
* fhandler.cc (fhandler_base::utimens): Replace fhandler_base::utimes.
Call utimens_fs.
* fhandler.h (class fhandler_base): Declare utimens_fs instead of
utimes_fs, utimens instead of utimes.
(class fhandler_disk_file): Declare utimens instead of utimes.
* fhandler_disk_file.cc (fhandler_disk_file::utimens): Replace
fhandler_disk_file::utimes.
(fhandler_base::utimens_fs): Replace fhandler_base::utimes_fs.
Implement tv_nsec handling according to SUSv4.
* syscalls.cc (utimensat): New function.
* times.cc (timespec_to_filetime): New function.
(timeval_to_timespec): New function.
(utimens_worker): Replace utimes_worker.
(utimes): Convert timeval to timespec and call utimens_worker.
(lutimes): Ditto.
(futimens): Take over implementation from futimes.
(futimes): Convert timeval to timespec and call futimens.
* winsup.h (timespec_to_filetime): Declare.
* include/cygwin/version.h: Bump API minor number.
* posix.sgml: Add SUSv4 section.  Add futimens and utimensat to it.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4117r2=1.4118
http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/cygwin.din.diff?cvsroot=srcr1=1.188r2=1.189
http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler.cc.diff?cvsroot=srcr1=1.320r2=1.321
http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler.h.diff?cvsroot=srcr1=1.341r2=1.342
http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_disk_file.cc.diff?cvsroot=srcr1=1.270r2=1.271
http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/posix.sgml.diff?cvsroot=srcr1=1.14r2=1.15
http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/syscalls.cc.diff?cvsroot=srcr1=1.488r2=1.489
http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/times.cc.diff?cvsroot=srcr1=1.94r2=1.95
http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/winsup.h.diff?cvsroot=srcr1=1.220r2=1.221
http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/cygwin/version.h.diff?cvsroot=srcr1=1.264r2=1.265

src/winsup/doc ChangeLog cygwin-api.in.sgml

[corinna]

CVSROOT:/cvs/src
Module name:src
Changes by: [EMAIL PROTECTED]   2008-04-24 10:00:04

Modified files:
winsup/doc : ChangeLog cygwin-api.in.sgml 

Log message:
* cygwin-api.in.sgml: Add std-susv4 section to Compatibility chapter.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/ChangeLog.diff?cvsroot=srcr1=1.143r2=1.144
http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/cygwin-api.in.sgml.diff?cvsroot=srcr1=1.6r2=1.7

src/winsup/cygwin ChangeLog fhandler_disk_file.cc

[corinna]

CVSROOT:/cvs/src
Module name:src
Changes by: [EMAIL PROTECTED]   2008-04-24 17:15:17

Modified files:
winsup/cygwin  : ChangeLog fhandler_disk_file.cc 

Log message:
* fhandler_disk_file.cc (fhandler_base::fstat_helper): Disable calling
pc.ndisk_links.  Just use nNumberOfLinks instead.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.4119r2=1.4120
http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_disk_file.cc.diff?cvsroot=srcr1=1.272r2=1.273

Re: wait.h

[Corinna Vinschen]

On Apr 23 14:18, Yaakov (Cygwin Ports) wrote:
 glibc ships a wait.h which contains only one line:

 #include sys/wait.h

 I know of at least three packages that #include wait.h instead of
 sys/wait.h.  Could such a header please be added to Cygwin (preferably
 to both branches)?

 Patch attached; I presume this is trivial enough to not require a
 copyright assignment.

Thanks, applied.  I won't apply it to the 1.5 branch, though.  Only
really important bugfixes should go there.  1.5 DLLs are a dying species.


Thanks,
Corinna

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

Re: wait.h

[Yaakov (Cygwin Ports)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Corinna Vinschen wrote:
| Thanks, applied.  I won't apply it to the 1.5 branch, though.  Only
| really important bugfixes should go there.  1.5 DLLs are a dying species.

Thank you.  (I'm a bit confused as to how endangered 1.5 is.)


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

iEYEAREIAAYFAkgRDTQACgkQpiWmPGlmQSNm4gCfWhBMBgK3s/L0ctEetfd7l+g/
ED8AniuZlXNvw4QqU7QqEYSBdY2A3E9d
=X/hf
-END PGP SIGNATURE-

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/

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/

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/

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/

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

[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: 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:
 http://cygwin.com/cygwin-ug-net/using-specialnames.html.
 
 

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: [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: Install cygwin in Win2K as nonadmin from CD make from WinXP

[Paul Domaskis]

Thorsten Kampe thorsten at thorstenkampe dot de 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/

[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 host port
  but there's no easy way to test UDP services. udp_client can be used
  to do this:
 udp_client host port or service name 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
  

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:
  http://cygwin.com/cygwin-ug-net/using-specialnames.html.
 
 

 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/

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: [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. smack/


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] 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 stdlib.h
Ansi says nothing about realpath(), so STRICT_ANSI requires that 
realpath is NOT declared when #include stdlib.h


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

[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] 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. smack/
|
| 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/

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

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

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=
+
+# Whether we need a single -rpath flag with a separated argument.

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/

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 host port
  but there's no easy way to test UDP services. udp_client can be used
  to do this:
 udp_client host port or service name 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
  

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.

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-

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-