Re: perl 5.10 and DynaLoader
2008/4/14, Yaakov (Cygwin Ports) <[EMAIL PROTECTED]>:
> Reini Urban wrote:
> | Bug confirmed.
> | I had problems with this also in B::C, but searched completely elsewhere.
> |
> | The next release will also change the archlib name to i686-cygwin as
> promised.
> | And the new build script with a sane install step.
>
> In the meantime, what's the fix?
There's none yet.
The two static archives for ('DynaLoader', 'Win32CORE') are missing
from the distro.
/usr/lib/perl5/5.10/i686-cygwin/auto/DynaLoader/DynaLoader.a
/usr/lib/perl5/5.10/i686-cygwin/auto/Win32CORE/Win32CORE.a
I'll have to check the Makefile changes why those static_ext are not
builded anymore.
I can post them here then.
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
--
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/
Missing header files
I am trying to compile wpa_supplicant for windows using cygwin. But the build fails due to missing header files in cygwin, like if_arp.h I could not find it in its default location i.e. /usr/include/net. I wonder if I need to install any specific package for getting these core network header files. I am specifically looking for the header files in the 'net' directory (i.e. /usr/include/net). Any help on how to get these header files would be greatly appreciated. Thanks, Asterix. Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ -- 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: perl 5.10 and DynaLoader
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Reini Urban wrote: | Bug confirmed. | I had problems with this also in B::C, but searched completely elsewhere. | | The next release will also change the archlib name to i686-cygwin as promised. | And the new build script with a sane install step. In the meantime, what's the fix? Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIAuf5piWmPGlmQSMRCIizAKC+HSBN4r/PT4FKaKmJNy41ymsxIQCfbON7 BJcd0iABWNSfEI2l6/Pn0d0= =H/dB -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: perl 5.10 and DynaLoader
2008/4/14, Yaakov (Cygwin Ports) <[EMAIL PROTECTED]>: > Yaakov (Cygwin Ports) wrote: > | Perl 5.10 no longer provides the static DynaLoader.a and Win32CORE.a > | modules. But while ExtUtils::Embed ldopts() does not list them, running > | xsinit() still generates code with boot_Socket and boot_Win32CORE, which > | then leads to undefined symbols at link time. > > s/Socket/DynaLoader/ Bug confirmed. I had problems with this also in B::C, but searched completely elsewhere. The next release will also change the archlib name to i686-cygwin as promised. And the new build script with a sane install step. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ -- 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: Vista + cygwin basics
Brian Dessent wrote: Correction - it doesn't try to do anything with the permissions as stated in the tarball. At startup it does try to set a DACL in the process token that contains Everyone:full. However, as I understand it, the DACL only applies to files created in situations where they would not otherwise inherit an ACL, so if the Vista default for C:\ contains inheritable settings (as I would imagine it has to) then this wouldn't apply. I used the Windows Properties dialog on C:\cygwin to add 'Administrator:Full Control' on my existing cygwin installation (since I had done very little personalization, there were no "private" files belonging to my unprivileged self to worry about). This propagated down to all contained objects. Now the perms/ACLs look a bit more sane. $ ls -l aatest.exe -rwxr-x---+ 1 Administrator Users 6144 Mar 20 13:53 aatest.exe $ getfacl aatest.exe # file: aatest.exe # owner: Administrator # group: Users user::rwx group::r-x group:SYSTEM:rwx group:Administrators:rwx mask:rwx other:--- It's not that anything was noticeably broken -- it's just that things looked so WEIRD I didn't really try to DO anything; afraid that I might have to wipe out any customizations and start over. Now, I've been involved with cygwin for a long time, but Vista+cygwin gives me the creeping heebie-jeebies...or maybe I'm just over-thinking it. -- 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: Vista + cygwin basics
Brian Dessent wrote: > Setup doesn't do anything with permissions, so the resulting ones are Correction - it doesn't try to do anything with the permissions as stated in the tarball. At startup it does try to set a DACL in the process token that contains Everyone:full. However, as I understand it, the DACL only applies to files created in situations where they would not otherwise inherit an ACL, so if the Vista default for C:\ contains inheritable settings (as I would imagine it has to) then this wouldn't apply. Brian -- 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: Vista + cygwin basics
Charles Wilson wrote: > So, are these differences expected? Have I messed up the installation > by doing 'Run as Administrator' -- some posts around the web seem to > recommned turning off UAC when running setup.exe, or running it in 'XP > Compatibility Mode'. Yes I would expect differences, given that Vista has very different defaults. No they shouldn't matter -- unless you're saying that something doesn't work. I don't think UAC should really matter, in that its heuristics are going to ask for permission to run it as administrator anyway (or at least, it should if it was named setup.exe; don't know about setup-n.exe.) It might be a different situation at runtime though, i.e. there still could be packages that don't yet have foo.exe.manifest-like workarounds discovered and implemented. Setup doesn't do anything with permissions, so the resulting ones are the defaults as inherited from the directory containing the location you chose to install. If you installed in c:\cygwin, they should have inherited from the default ACL in c:\, whatever Vista chose for that. The striking difference could be due to this, i.e. MS tightended down the root dir default ACLs since you don't typically install things there but instead in Program Files. If you want them different, simply create the root dir with the desired permissions before installing. I'll look at that empty glib2-runtime package and see what the deal there is. Brian -- 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: Attn: cygport maintainer [was: Re: Libtool 2.2.2]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Charles Wilson wrote: | I believe this was an attempt at optimization: avoid testing for | specific tools need only on one platform, unless libtool has been told | that it is ON that platform. Oddly, you'd think that libtool would | figure that out from $build/$host/$target, and not [win32-dll]. More than that, is AC_LIBTOOL_WIN32_DLL (now [win32-dll]) actually necessary anymore? Cygwin doesn't need it, but I don't know about MinGW. | Which is also odd. I wonder why linux uses objdump...maybe this is a | dead code path? I'm not sure; AFAICS such a test didn't exist for linux in libtool 1.5. | [*] Having heard no objections, and a few votes in favor, I'm leaning | towards replacing both libtool1.5 and libtool2.2 with a single | "libtool" package, with 1.5-derived versions remaining "curr:" for the | near-term. With my patch to libtool and some tweaking of cygport, libtool 2.2 seems to be working pretty well. I will need to know your final decision before committing the cygport patches, and I'll try to push an update as soon as possible thereafter. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIAtMzpiWmPGlmQSMRCE3eAJ9mQXitBbfqWUnLRFL7HmalQaG2fgCeLd/A yA/G/Orc2yZcwB7GVikWUI4= =N1Er -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: Attn: cygport maintainer [was: Re: Libtool 2.2.2]
Yaakov (Cygwin Ports) wrote: One more patch will be required, namely, to define OBJDUMP where necessary. I've rolled these two patches together, as attached. Explanation: The AC_LIBTOOL_WIN32_DLL macro was supposed to be used in packages which built on Win32 platforms, in order to create DLLs. This macro tested for as, dlltool, and objdump. The latter is used in the file_magic test to determine if a .a is a static or import library. In 1.5 libtool worked anyway without it, because among other variables, OBJDUMP was given a "sane default" near the beginning of libtool.m4 and was always exported, and AS and DLLTOOL weren't needed. > But in 2.2, the "sane defaults" have been minimized, and OBJDUMP is no longer defined by default, I believe this was an attempt at optimization: avoid testing for specific tools need only on one platform, unless libtool has been told that it is ON that platform. Oddly, you'd think that libtool would figure that out from $build/$host/$target, and not [win32-dll]. so without the win32-dll arg to LT_INIT (or the AC_LIBTOOL_WIN32_DLL compat macro), libtool refuses to link shared libs against non-libtoolized shared libs, because the file_magic test on the implib fails due to an undefined OBJDUMP variable. Assuring that OBJDUMP is defined is therefore necessary for compatibility with previous behaviour. Not only that, but this may fix another possible bug on Linux ELF systems, as there is a test on that platform (line 2461 after the patch) which uses OBJDUMP, which I don't see where it would have been defined. Which is also odd. I wonder why linux uses objdump...maybe this is a dead code path? Oh, well: if it's necessary, it's necessary, and I'll push it upstream as well as including it in my next release of libtool2.2 (or "libtool" [*]). Thanks for doing this, Yaakov. -- Chuck [*] Having heard no objections, and a few votes in favor, I'm leaning towards replacing both libtool1.5 and libtool2.2 with a single "libtool" package, with 1.5-derived versions remaining "curr:" for the near-term. In the medium term, I expect that prev: will be the latest-1.5 derivative, and curr:/test: will both be 2.2-derived. Long term, libtool-1.5 will disappear from the standard prev:/curr:/test: trio, but setup's chooser should still allow the determined user to find a 1.5 variant if they click enough. -- 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/
Vista + cygwin basics
So, I'm taking the plunge...but I have a few questions. Here's what I've done so far: (1) using setup-2.588 snapshot (2) Ran as Administrator. Note that I was logged in as my normal user account, which is NOT a member of the Administrators group. So, I right-clicked on setup-2.588.exe, and chose 'Run as Administrator'. This gave me the UAC popup, with my choice of Administrative accounts: a) the regular ComputerOwner account that was pre-configured on my comptuer, and is a member of the Administrators group b) the hidden "real" Administrator account http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9015738&pageNumber=2 (I chose to use the real 'Administrator' account) (3) selected my favorite packages (4) installed. There are a few things I noticed that were/are odd. (1) The installation reported an error 2008/04/13 03:08:21 mbox note: Can't open file://C:\Users\cwilson\Desktop\cygwin-local/http%3a%2f%2fmirrors.xmission.com%2fcygwin/release/GNOME/glib2/glib2-runtime/glib2-runtime-2.10.3-1.tar.bz2 for reading: Invalid or unsupported tar format This seems related to this: http://cygwin.com/ml/cygwin-apps/2008-04/msg00104.html but I thought these were all fixed http://cygwin.com/ml/cygwin-apps/2008-04/msg00105.html And besides, my copy of glib2-runtime-2.10.3-1.tar.bz2 IS 46 bytes, and 'tar tvjf' doesn't seem to have a problem with it. (2) Many of the installed files look like this: $ ls -l aatest.exe r-x---+ 1 Administrator Users 6144 Mar 20 13:53 aatest.exe $ getfacl aatest.exe # file: aatest.exe # owner: Administrator # group: Users user::--- group::r-x group:SYSTEM:rwx group:Administrators:rwx mask:rwx other:--- Compare this to my XP machine, in which I typically run setup.exe under my normal user account (which is a member of the Administrators group): $ ls -l aatest.exe -rwxr-x---+ 1 cwilson Users 6144 Mar 20 13:53 aatest.exe $ getfacl aatest.exe # file: aatest.exe # owner: cwilson # group: Users user::rwx group::r-x group:SYSTEM:rwx group:Administrators:rwx mask:rwx other:--- What puzzles me here is that the nominal owner on Vista, 'Administrator' does not appear to have the user permission bits/ACL entry. (3) Symlinks look like this: $ ls -l aclocal lrwxrwxrwx 1 Administrator None 25 Apr 13 03:19 aclocal -> /etc/alternatives/aclocal $ getfacl aclocal # file: aclocal # owner: Administrator # group: Users user::--- group::r-x group:SYSTEM:rwx group:Administrators:rwx mask:rwx other:--- By way of comparison, on XP: $ ls -l aclocal lrwxrwxrwx 1 cwilson Users 25 Aug 20 2005 aclocal -> /etc/alternatives/aclocal* $ getfacl aclocal # file: aclocal # owner: cwilson # group: Users user::rwx group::r-x group:SYSTEM:rwx group:Administrators:rwx mask:rwx other:--- Once again, it seems odd that on Vista, the nominal owner has no 'user' permissions in the ACL list (even though symlinks are always 'ls -l'ed as lrwxrwxrwx) (4) and directories look like this: $ ls -ld etc d---r-x---+ 20 Administrator Users 12288 Apr 13 03:25 etc $ getfacl etc # file: etc # owner: Administrator # group: Users user::--- group::r-x group:SYSTEM:rwx group:Administrators:rwx mask:rwx other:--- default:group:SYSTEM:rwx default:group:Administrators:rwx default:group:Users:r-x default:mask:rwx Again, by comparison on XP: $ ls -ld etc drwxrwxr-x+ 25 cwilson Users 0 Apr 13 00:28 etc/ $ getfacl etc # file: etc # owner: cwilson # group: Users user::rwx group::rwx group:SYSTEM:rwx group:Administrators:rwx mask:rwx other:r-x default:user::rwx default:group:SYSTEM:rwx default:group:Administrators:rwx default:group:Users:rwx default:mask:rwx So, are these differences expected? Have I messed up the installation by doing 'Run as Administrator' -- some posts around the web seem to recommned turning off UAC when running setup.exe, or running it in 'XP Compatibility Mode'. What is the official recommendation for installing cygwin on Vista? -- 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: Which tool to convert pictures into a nice web page
Morten Kjærulff hotmail.com> writes: > > > Hi, > > I have a bunch of picture files from a web cam in a directory. The files changes over time (some go, new ones come). > > Which tool (that comes with cygwin) can I use to make a nice web page, that I can upload to my homepage? > > What I would like to do, is some like this: > > somekindofcommand --swithcestosayhowmypageshouldlooklike inputdirectorywithpicturefiles outputdirectorywithhtmlfiles > > and then run it each 10 minutes, and ftp it to my homepage (I know how to do this). > > Cheers, > Morten > _ > Spil Sten Saks Papir mod dine venner i Messenger > http://www2.messengerplayground.dk/spil/102?cmp=text_stensakspapir > > Pictools may help you build what you want. I wrote it to help put my own pictures on the web, as in http://physpics.com/annals/2007/Fall/pix/Clouds/index.html The tools and lots of documentation are at http://physpics.com/pictools/ Fred Hansen -- 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: libpopt0 is missing - cygpopt-0.dll missing
Peter Bennett wrote: > Current downloads of Cygwin packages are missing cygpopt-0.dll. This is > supposed to be packaged as libpopt0, but that package is not on any > mirror that I can find. Result is dos2unix, unix2dos, d2u, u2d do not Whatever method you're using to determine that this package is missing is incorrect. Here's a random sample of 4 http mirrors, all working fine: $ for m in http://mirrors.xmission.com/cygwin \ http://mirrors.kernel.org/sourceware/cygwin \ http://mirror.csclub.uwaterloo.ca/cygwin \ http://cygwin.elite-systems.org; do \ wget -nv $m/release/popt/libpopt0/libpopt0-1.6.4-4.tar.bz2; done 17:58:02 URL:http://mirrors.xmission.com/cygwin/release/popt/libpopt0/libpopt0-1.6.4-4.tar.bz2 [11627/11627] -> "libpopt0-1.6.4-4.tar.bz2" [1] 17:58:07 URL:http://mirrors.kernel.org/sourceware/cygwin/release/popt/libpopt0/libpopt0-1.6.4-4.tar.bz2 [11627/11627] -> "libpopt0-1.6.4-4.tar.bz2.1" [1] 17:58:07 URL:http://mirror.csclub.uwaterloo.ca/cygwin/release/popt/libpopt0/libpopt0-1.6.4-4.tar.bz2 [11627/11627] -> "libpopt0-1.6.4-4.tar.bz2.2" [1] 17:58:08 URL:http://cygwin.elite-systems.org/release/popt/libpopt0/libpopt0-1.6.4-4.tar.bz2 [11627/11627] -> "libpopt0-1.6.4-4.tar.bz2.3" [1] Brian -- 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: libpopt0 is missing - cygpopt-0.dll missing
On Sun, Apr 13, 2008 at 08:32:58PM -0400, Peter Bennett wrote: >Current downloads of Cygwin packages are missing cygpopt-0.dll. This is >supposed to be packaged as libpopt0, but that package is not on any >mirror that I can find. Result is dos2unix, unix2dos, d2u, u2d do not >work. They terminate with a 53 return code without doing anything and >without displaying any message. I solved it by copying cygpopt-0.dll >from an earlier install (several years old). For the benefit of others, >please can somebody get that package back in the distribution. The package *is* in the distribution. Check out http://cygwin.com/packages/ . 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/
libpopt0 is missing - cygpopt-0.dll missing
Current downloads of Cygwin packages are missing cygpopt-0.dll. This is supposed to be packaged as libpopt0, but that package is not on any mirror that I can find. Result is dos2unix, unix2dos, d2u, u2d do not work. They terminate with a 53 return code without doing anything and without displaying any message. I solved it by copying cygpopt-0.dll from an earlier install (several years old). For the benefit of others, please can somebody get that package back in the distribution. Thanks Peter Bennett -- 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: perl 5.10 and DynaLoader
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Yaakov (Cygwin Ports) wrote: | Perl 5.10 no longer provides the static DynaLoader.a and Win32CORE.a | modules. But while ExtUtils::Embed ldopts() does not list them, running | xsinit() still generates code with boot_Socket and boot_Win32CORE, which | then leads to undefined symbols at link time. s/Socket/DynaLoader/ Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIApxapiWmPGlmQSMRCKFeAKDjK5NzEt95nlc6WIoS+N6yTLGuLgCgqNE3 Bk4SrpP7uQXfL9L3C92sjY0= =dYaD -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: segmentation faults and memory problems
Eric Tea wrote: > I work on two computers, running under > windows XP and windows XP64. The former have 1Gb of RAM and the latter > 4Gb. > Increasing the stack size and modifying the > "heap_chunk_in_mb" value dont change anything to my segmentation > fault. > Plus "max_memory" always reply 1536Mb for both > computers and for any "heap_chunk_in_mb" value (so i think i > am not RAM limitted It doesn't matter how much physical memory you have. 32 bit Windows (and note that when using Cygwin with XP x64 you are still using 32 bit mode, WOW64, as there is no x64 Cygwin) partitions the virtual memory space into 2GB for kernel mode and 2GB for user mode. So you start out with a hard limit of 2GB of virtual address space, from which is subtracted the virtual memory of all DLLs, mappings, the stack, etc. in the process. For a single allocation, a limit of 1.5 GB sounds about right, given that the space is greatly fragmented by all those DLLs. There is a /3GB switch you can add to boot.ini which changes the partitioning to 3GB user mode and 1GB kernel mode. However, in order for apps to take advantage of this they have to be recompiled with a "/3GB aware" flag set in their PE header. And I'm not even sure if Cygwin can work in this mode; check the archives. Brian -- 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/
perl 5.10 and DynaLoader
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Reini, Perl 5.10 no longer provides the static DynaLoader.a and Win32CORE.a modules. But while ExtUtils::Embed ldopts() does not list them, running xsinit() still generates code with boot_Socket and boot_Win32CORE, which then leads to undefined symbols at link time. Could you please clarify? Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIApOOpiWmPGlmQSMRCN0DAJ9levxntZ4xLF3cjj/Ocfe4XtwsvwCgjU+2 pWqgHymXzTCJPZ3WDHIkapY= =g8ti -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: [HEADSUP] Let's start a Cygwin 1.7 release area
On Sun, Apr 13, 2008 at 03:06:36PM +0200, Angelo Graziosi wrote: >I think you have already the solution, but for the sake of >completeness: what would it happen if one installs/uninstalls Cygwin >and/or Cygwin-1.7 leaving a dirty registry? Apparently you are monitoring the cygwin-apps mailing list. Please don't hijack the discussion and move it elsewhere. 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/
[Attn: netpbm maintainer] Packaging bugs and problem with ppmtogif
Hi ppmtogif produces only black gif images. For example: gs -sDEVICE=ppmraw -sOutputFile=/tmp/tiger.ppm /usr/share/ghostscript/8.62/examples/tiger.eps ppmtogif.exe tiger.ppm > tiger.gif Also there are 2 packaging bugs in netpbm o http://sourceware.org/ml/cygwin/2008-03/msg00567.html o http://sourceware.org/ml/cygwin/2008-02/msg00645.html Ciao Volker -- 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/
segmentation faults and memory problems
Hi, I try to run a program which needs a lot of memory. It fails with a "segmentation fault". In the program's Users Guide, it is advised to increase the stack size but as knwon the "ulimit -s" command does not work. So i tried to compile the program with "-Wl,stack=..." option but it still failed. I found in the FAQs some solutions like increasing cygwin's memory using regtool. And it is still failing. I ran the "max_memory" code given in the FAQ and it always gives 1536.0Mb and it is very weird... I work on two computers, running under windows XP and windows XP64. The former have 1Gb of RAM and the latter 4Gb. Increasing the stack size and modifying the "heap_chunk_in_mb" value dont change anything to my segmentation fault. Plus "max_memory" always reply 1536Mb for both computers and for any "heap_chunk_in_mb" value (so i think i am not RAM limitted ref:<[EMAIL PROTECTED]>) I'm running out of solutions. Can someone help? I attach the cygcheck.out file for the first computer. Tea Eric PhD student, IEF, Université Paris-Sud, FRANCE cygcheck.out Description: Binary data -- 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/
cygwin-1.7 utf8 path support (exp)
Attached patch is for interested developers which want to try out the
upcoming cygwin-1.7
for utf8 path conversion support. It uses now the wide char api with
MAX_PATH of 32KB length.
Do not apply yet.
The cygwin 1.7 gcc suite is not yet stable enough to finish perl
compilation for me
so I couldn't test it. Maybe someone else is more lucky.
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
diff -bu perl-current/cygwin/cygwin.c.orig perl-current/cygwin/cygwin.c
--- perl-current/cygwin/cygwin.c.orig 2007-12-22 22:38:46.0 +0100
+++ perl-current/cygwin/cygwin.c 2008-04-13 14:24:16.87500 +0200
@@ -10,9 +10,13 @@
#include
#include
#include
+#include
#include
#include
#include
+#if (CYGWIN_VERSION_API_MINOR >= 181)
+#include
+#endif
/*
* pp_system() implemented via spawn()
@@ -191,7 +195,12 @@
pid = (pid_t)SvIV(ST(0));
-if ((RETVAL = cygwin32_winpid_to_pid(pid)) > 0) {
+#if (CYGWIN_VERSION_API_MINOR >= 181)
+RETVAL = cygwin_winpid_to_pid(pid);
+#else
+RETVAL = cygwin32_winpid_to_pid(pid);
+#endif
+if (RETVAL > 0) {
XSprePUSH; PUSHi((IV)RETVAL);
XSRETURN(1);
}
@@ -205,6 +214,7 @@
STRLEN len;
int err;
char *pathname, *buf;
+int isutf8 = 0;
if (items < 1 || items > 2)
Perl_croak(aTHX_ "Usage: Cygwin::win_to_posix_path(pathname, [absolute])");
@@ -215,14 +225,58 @@
if (!len)
Perl_croak(aTHX_ "can't convert empty path");
-buf = (char *) safemalloc (len + 260 + 1001);
+isutf8 = SvUTF8(ST(0));
+#if (CYGWIN_VERSION_API_MINOR >= 181)
+/* Check utf8 flag and use wide api then.
+ Size calculation: On overflow let cygwin_conv_path calculate the final size.
+ */
+if (isutf8) {
+ int what = absolute_flag ? CCP_WIN_W_TO_POSIX : CCP_WIN_W_TO_POSIX | CCP_RELATIVE;
+ int wlen = sizeof(wchar_t)*(len + 260 + 1001);
+ wchar_t *wpath = (wchar_t *) safemalloc(sizeof(wchar_t)*len);
+ wchar_t *wbuf = (wchar_t *) safemalloc(wlen);
+ set_locale(LC_CTYPE, "utf8");
+ if (!IN_BYTES) {
+ mbstate_t mbs;
+ /* utf8_to_uvuni(pathname, wpath) or Encoding::_utf8_to_bytes(sv, "UCS-2BE"); */
+ wlen = mbsrtowcs(wpath, (const char**)&pathname, wlen, &mbs);
+ if (wlen > 0)
+ err = cygwin_conv_path(what, wpath, wbuf, wlen);
+ } else { /* use bytes; assume already ucs-2 encoded bytestream */
+ err = cygwin_conv_path(what, pathname, wbuf, wlen);
+ }
+ if (err == ENOSPC) { /* our space assumption was wrong, not enough space */
+ int newlen = cygwin_conv_path(what, wpath, wbuf, 0);
+ wbuf = (wchar_t *) realloc(&wbuf, newlen);
+ err = cygwin_conv_path(what, wpath, wbuf, newlen);
+ wlen = newlen;
+ }
+ /* uvuni_to_utf8(buf, chr) or Encoding::_bytes_to_utf8(sv, "UCS-2BE"); */
+ wlen = wcsrtombs(NULL, (const wchar_t **)&wbuf, wlen, NULL);
+ buf = (char *) safemalloc(wlen+1);
+ wcsrtombs(buf, (const wchar_t **)&wbuf, wlen, NULL);
+} else {
+ int what = absolute_flag ? CCP_WIN_A_TO_POSIX : CCP_WIN_A_TO_POSIX | CCP_RELATIVE;
+ buf = (char *) safemalloc (len + 260 + 1001);
+ err = cygwin_conv_path(what, pathname, buf, len + 260 + 1001);
+ if (err == ENOSPC) { /* our space assumption was wrong, not enough space */
+ int newlen = cygwin_conv_path(what, pathname, buf, 0);
+ buf = (char *) realloc(&buf, newlen);
+ err = cygwin_conv_path(what, pathname, buf, newlen);
+ }
+}
+#else
if (absolute_flag)
err = cygwin_conv_to_full_posix_path(pathname, buf);
else
err = cygwin_conv_to_posix_path(pathname, buf);
+#endif
if (!err) {
ST(0) = sv_2mortal(newSVpv(buf, 0));
+ if (isutf8) {
+ SvUTF8_on(ST(0));
+ }
safefree(buf);
XSRETURN(1);
} else {
@@ -238,24 +292,71 @@
STRLEN len;
int err;
char *pathname, *buf;
+int isutf8 = 0;
if (items < 1 || items > 2)
Perl_croak(aTHX_ "Usage: Cygwin::posix_to_win_path(pathname, [absolute])");
-pathname = SvPV(ST(0), len);
+pathname = SvPVx(ST(0), len);
if (items == 2)
absolute_flag = SvTRUE(ST(1));
if (!len)
Perl_croak(aTHX_ "can't convert empty path");
+isutf8 = SvUTF8(ST(0));
+#if (CYGWIN_VERSION_API_MINOR >= 181)
+/* Check utf8 flag and use wide api then.
+ Size calculation: On overflow let cygwin_conv_path calculate the final size.
+ */
+if (isutf8) {
+ int what = absolute_flag ? CCP_POSIX_TO_WIN_W : CCP_POSIX_TO_WIN_W | CCP_RELATIVE;
+ int wlen = sizeof(wchar_t)*(len + 260 + 1001);
+ wchar_t *wpath = (wchar_t *) safemalloc(sizeof(wchar_t)*len);
+ wchar_t *wbuf = (wchar_t *) safemalloc(wlen);
+ set_locale(LC_CTYPE, "utf8");
+ if (!IN_BYTES) {
+ mbstate_t mbs;
+ /* utf8_to_uvuni(pathname, wpath) or Encoding::_utf8_to_bytes(sv, "UCS-2BE"); */
+ wlen = mbsrtowcs(wpath, (const char**)&pathname, wlen, &mbs);
+ if (wlen > 0)
+ err = cygwin_conv_path(what, wpath, wbuf, wlen);
+ } else { /* use bytes; assume already ucs-2 encoded bytestream */
+ err = cygwin_conv_path(what, pathname, wb
Something weird is happening with endlessly updated setup.ini
The file setup.ini has been updated 3 times in the last, dunno, 18 hours or so, and the only change has been a new version of _update-info-dir. Is there a reason for this? (Well, I'm sure there's a reason.) Fergus -- 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: [HEADSUP] Let's start a Cygwin 1.7 release area
I think you have already the solution, but for the sake of completeness: what would it happen if one installs/uninstalls Cygwin and/or Cygwin-1.7 leaving a dirty registry? Cheers, Angelo. --- Tu proverai si' come sa di sale lo pane altrui, e come e' duro calle lo scendere e 'l salir per l'altrui scale. - DANTE, Paradiso, xvii 58-60 -- 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: Attn: cygport maintainer [was: Re: Libtool 2.2.2]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Charles Wilson wrote: | Yaakov (Cygwin Ports) wrote: |> AU_DEFUN([AC_PROG_LIBTOOL], |> [LT_INIT |> LT_OUTPUT |> AC_DIAGNOSE([obsolete], |> [$0: Remove this warning and the call to LT_OUTPUT if you do not need |> libtool to exist before AC_OUTPUT.]) |> ]) |> |> AU_ALIAS([AM_PROG_LIBTOOL], [AC_PROG_LIBTOOL]) | | That looks OK to me. I'll include something like this in the next | version of libtool2.2 (or "libtool" test: 2.2). One more patch will be required, namely, to define OBJDUMP where necessary. I've rolled these two patches together, as attached. Explanation: The AC_LIBTOOL_WIN32_DLL macro was supposed to be used in packages which built on Win32 platforms, in order to create DLLs. This macro tested for as, dlltool, and objdump. The latter is used in the file_magic test to determine if a .a is a static or import library. In 1.5 libtool worked anyway without it, because among other variables, OBJDUMP was given a "sane default" near the beginning of libtool.m4 and was always exported, and AS and DLLTOOL weren't needed. But in 2.2, the "sane defaults" have been minimized, and OBJDUMP is no longer defined by default, so without the win32-dll arg to LT_INIT (or the AC_LIBTOOL_WIN32_DLL compat macro), libtool refuses to link shared libs against non-libtoolized shared libs, because the file_magic test on the implib fails due to an undefined OBJDUMP variable. Assuring that OBJDUMP is defined is therefore necessary for compatibility with previous behaviour. Not only that, but this may fix another possible bug on Linux ELF systems, as there is a test on that platform (line 2461 after the patch) which uses OBJDUMP, which I don't see where it would have been defined. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIAeHppiWmPGlmQSMRCLo1AKDx1ENwmwMhmKvL12avJ1RuVJfBHACg2g69 NKjvebLP38bbNdqP/cis8GI= =Z4Tf -END PGP SIGNATURE- --- libltdl/m4/libtool.m4 2008-04-01 13:20:04.0 -0500 +++ /usr/share/aclocal/libtool.m4 2008-04-13 05:21:22.296875000 -0500 @@ -99,8 +99,15 @@ ])# LT_INIT # Old names: -AU_ALIAS([AC_PROG_LIBTOOL], [LT_INIT]) -AU_ALIAS([AM_PROG_LIBTOOL], [LT_INIT]) +AU_DEFUN([AC_PROG_LIBTOOL], +[LT_INIT +LT_OUTPUT +AC_DIAGNOSE([obsolete], +[$0: Remove this warning and the call to LT_OUTPUT if you do not need +libtool to exist before AC_OUTPUT.]) +]) + +AU_ALIAS([AM_PROG_LIBTOOL], [AC_PROG_LIBTOOL]) dnl aclocal-1.4 backwards compatibility: dnl AC_DEFUN([AC_PROG_LIBTOOL], []) dnl AC_DEFUN([AM_PROG_LIBTOOL], []) @@ -2026,6 +2033,7 @@ [AC_REQUIRE([AC_CANONICAL_HOST])dnl m4_require([_LT_DECL_EGREP])dnl m4_require([_LT_FILEUTILS_DEFAULTS])dnl +m4_require([_LT_DECL_OBJDUMP])dnl m4_require([_LT_DECL_SED])dnl AC_MSG_CHECKING([dynamic linker characteristics]) m4_if([$1], @@ -2947,6 +2955,7 @@ # -- PORTME fill in with the dynamic library characteristics m4_defun([_LT_CHECK_MAGIC_METHOD], [m4_require([_LT_DECL_EGREP]) +m4_require([_LT_DECL_OBJDUMP]) AC_CACHE_CHECK([how to recognize dependent libraries], lt_cv_deplibs_check_method, [lt_cv_file_magic_cmd='$MAGIC_CMD' @@ -6961,6 +6970,18 @@ ]) +# _LT_DECL_OBJDUMP +# -- +# If we don't have a new enough Autoconf to choose the best objdump +# available, choose the one first in the user's PATH. +m4_defun([_LT_DECL_OBJDUMP], +[AC_CHECK_TOOL(OBJDUMP, objdump, false) +test -z "$OBJDUMP" && OBJDUMP=objdump +_LT_DECL([], [OBJDUMP], [1], [An object symbol dumper]) +AC_SUBST([OBJDUMP]) +]) + + # _LT_DECL_SED # # Check for a fully-functional sed program, that truncates -- 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: How do I run sshd as a particular user?
On Apr 13 03:27, Robert McKay wrote: > On Sat, Apr 12, 2008 at 10:06 AM, Corinna Vinschen > <[EMAIL PROTECTED]> wrote: http://cygwin.com/acronyms/#PCYMTNQREAIYR > > On Apr 12 01:11, Robert McKay wrote: > > > In order to run sshd as an unprivileged user I had to use a nasty > > > hexedit hack on the sshd.exe file to replace the seteuid() call (which > > > fails / returns -1 without admin privileges and causes sshd to exit) > > > with a call to isalpha() which has (almost) the same function > > > prototype, but always returns 0 unless your userid 'is an alphanumeric > > > charater' :) > > > > Argh! > > > > I don't know what you're doing wrong but this is *totally* unnecessary. > > You can run sshd as unprivileged user without having to change the > > sshd code. You can do this while another sshd is running on > > port 22 under a privileged account. What the user has to do is to create > > her own sshd_config file and own host keys. If no other sshd is running > > on the machine, just chown the host key files in /etc and switch off > > privilege separation in /etc/sshd_config. > > Interesting.. are you sure your account doesn't have the allow replace > process token privilege? Yes. The account was created as standard user account for the purpose of testing Cygwin with non-privileged user accounts. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
ncurses with wide char support
Hi, I would like to compile snownews last version with utf-8 support. In the FAQ he said that I need to have ncurses with wide char support (libncursesw). http://www.kcore.de/wiki/wiki.cgi?Snownews/FAQ#How_can_I_get_full_Unicode_support I can't see this package in the list of cygwin package. Is this support exist for cygwin ? Regards. -- Didier Bretin http://bretin.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/
