Re: [PATCH] Change linker to gcc for cygwin
> On Aug 15, 2015, at 7:52 AM, Achim Gratz wrote: > > [Cygwin Perl maintainer here] > > Ivan Pozdeev writes: >> Currently, g++ is specified in hints/cygwin.sh >> It is quite a weighty install - approaches 100M with dependencies - >> and since it isn't really needed (see below), requiring it is >> completely unnecessary. >> Moreover, as a consequence, it's also required when building modules. > > I'm in general sympathetic with trying to keep dependencies small. yes, g++ is not required, only for -devel. g++ is not needed as perl run-time dep, only as build dep and devel dep, for people compiling XS modules. >> The current choice was introduced in commit >> 4f3b19ea9f1065e1d9d263b4c07fca1ba8f29276 >> as a replacement for `ld2'; related cygwin maillist message by Reini Urban: >> https://www.cygwin.com/ml/cygwin/2007-07/msg00665.html >> Neither the message not the linked perl5-porters thread contain any >> information on the choice of g++ over gcc. >> >> Maybe Reini himself can comment on his decision? g++ as ld was needed to be able to link C++ projects which also link to libperl, like gnome I think. > Maybe you could discuss things concerning Cygwin on the Cygwin mailing > list first before proposing changes for Cygwin upstream. I don't > pretend to know every detail of how and where Perl is used on Cygwin and > you shouldn't either. Maybe using g++ as a linker was something that > just happened or for reasons that are not valid anymore, but it's one of > the things I wouldn't want to change on a whim. It is still valid, Yaakov needed that. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: perl-5.18.2-1 (x86) [test] Attn Maintainers with perl reqs
On May 2, 2014, at 3:32 AM, Achim Gratz wrote: > Reini Urban writes: >> perl, perl_vendor, perl_manpages, perl_debugbuild > > The debug package is actually named perl_debuginfo at the moment, but > perhaps it should be renamed perl-debuginfo to conform to all other > packages? probably. I also found out that several vendor packages are now separated on x86_64, so I’ll have to split them also for 32bit. Lot more work todo for me, but apparently some guys just went ahead. > @INC looks strange: why do you keep vendor_perl for 5.10, but not for > 5.14? Do we really want to fall back to site_perl 5.10 and 5.8 these > days? oops, vendor_perl/5.14 is missing. yes, falling back to good old arch-unspecific code is no problem and saves installation time and space. and we did support those versions. still working on unexpected socketpair problems with 64bit. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: perl-5.18.2-1 (x86) [test] Attn Maintainers with perl reqs
I've uploaded the first test packages for the new perl-5.18.2, x86 only, today, as test package. Most problems in the last weeks were on 32bit only, 64bit has a much better address space. perl, perl_vendor, perl_manpages, perl_debugbuild I'll upload the new 64bit version and my own missing perl subpackages in the next few days also. No problems expected, as my smoker is pretty stable on 64bit. Note that perl-5.18 has some new and maybe unexpected syntax warnings. And there are still some minor bugs lurking. That's the price we have to pay. See http://perldoc.perl.org/index-history.html There are also some shiny new features, such as with Unicode. I'll probably skip 5.20, and wait for 5.22 as this will probably have improved hashtables and better security. Changes: - updated perlrebase to use the rebase -s database with a systemperl in /usr/bin - improved automatic rebase with EUMM, not with Module::Build (using rebase -s) - changed gcc-4 to gcc, g++-4 to g++ as there are no -4 variants anymore Changes in perl_vendor: - Replaced Crypt::SSLeay for CPAN::Reporter with Net::SSLeay, LWP::Protocol::https and IO::Socket::SSL to support hostname verification. In the next few weeks I hope that all maintainers with perl as requirement will have updated their packages as test, or can verify that they don't need to update, so that we can have a unified switch over as with 5.14. Only packages which link to libperl or are building XS libs need to update as soon as possible. The others might want to check if their perl scripts are still running, so that the pain after the switch is minimized. It's really easy now with cygport and only 2 lines needed: CPAN_AUTHOR=who inherit perl It's only 173 setup.hints in those packages :) perl/perl-libwin32 perl/perl-Win32-GUI parrot/parrot-devel parrot/rakudo-star perl-ExtUtils-Depends perl-Clone perl/perl-Text-CSV ?? perl/perl-Text-CSV_XS perl/perl-IO-Tty perl/perl-Error delta copyright-update cvsutils autobuild postgresql/postgresql-plperl openssl sendxmpp groff/groff-perl perl-Locale-gettext perl-Tk subversion weechat/weechat-perl gtk-doc stow help2man w3m icon-naming-utils texi2html atool llvm/clang-analyzer cdrkit/genisoimage man/manlint stunnel snownews grepmail ddir libproxy/perl-Net-Libproxy TeXmacs openldap/openldap-server boost/libboost-devel colorgcc net-snmp libbonobo2 quilt lftp monotone mm-common netpbm vim/vim-common docbook-utils aspell -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: GIT (was: Coverity Scan)
On Fri, Apr 25, 2014 at 11:22 AM, Corinna Vinschen wrote: > On Apr 25 15:24, Jim Garrison wrote: >> > Corinna Vinschen >> > > >Yeah, I'm n ot exactly looking forward to it since I'm very familiar >> > > >with CVS or SVN, but have nothing but trouble with git. But since >> > > >everybody else is so very happy with git, I guess I'll have to adapt. >> > > >Teeth-gnashingly. >> >> I recently went through the same reluctant switch to Git from SVN. >> >> I can tell you from personal experience that there's a period of >> disorientation when even the simplest tasks require a quick trip to Google. >> And Git requires a major shift in your mental model of how things work. >> Instead of 2 places where stuff is (local and remote) there are now 4 >> (workspace, stage, local repo, remote repo). ... > Yeah, I'm trying to get a grip via "the book" http://git-scm.com/book/ Only experience helps. I needed about a year to not loose too much changes after the switch from svn to git, but feeling very happy now. It helps having backups for the beginning if you try out rebase or reset --hard or git pull --force. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin 1.7.25-1.7.28 - the perl process couldn't wake up after system call
On Mon, Apr 7, 2014 at 11:37 AM, Larry Hall (Cygwin) wrote: > On 4/7/2014 8:03 AM, Eduard wrote: >> >> Hi, >> We run >> Cygwin 1.7.25-1.7.28 on Win7-64bit. >> perl version is v5.14.2. >> >> Sometimes during system call from perl we see the following error: >> 0 [sig] perl 9852 stopped_or_terminated: couldn't wake up wait event >> 0x110, Win32 error 6 >> >> The process hangs and cannot be terminated by kill command. The only >> way to kill process is with windows task manager. >> Our tasks require many system calls to complete >> Please advise how to resolve this. Eduard: Please advise (off-list if too much data) how I could reproduce this problem. I never stumbled on that. Esp. the 64 bit version is much safer than the 32bit version. > Is it any better or worse with Cygwin 1.7.29 that was just released? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Executing a perl script from Windows 7
perl core has a script called pl2bat.pl to create an executable bat file. It's in win32/bin/pl2bat.pl See http://perl5.git.perl.org/perl.git/blob_plain/HEAD:/win32/bin/pl2bat.pl -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: gcc-4.7.3-1
On Tue, Dec 17, 2013 at 11:04 AM, marco atzeri wrote: ... Note that this also needs to be done when building perl XS extensions. With the next perl update we will use gcc then. > in your ~/bin or /usr/local/bin > ln -s /usr/bin/gcc gcc4 -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: C:\cygwin\bin\cyggcc_s-1.dll: Loaded to different address
On Wed, Dec 4, 2013 at 2:18 PM, bartel wrote: > Rebase is fine now; all I get is this harmless (?) message: > > /usr/lib/perl5/5.14/i686-cygwin-threads-64int/CORE/cygperl5_14_2.dll: > skipped because nonexistent. > > Nonexistent is not the whole truth: it's just a dangling symlink. > Sibling cygperl5_14.dll is fine > Is that a bug or my doing? That is a known packaging glitch in perl, yes. You can ignore it. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: mosh-1.2.4-2 (x86)
I've fixed mosh on x86 adding the missing /usr/bin/mosh perl-wrapper, not x86_64 not needed. Thanks to Egon Ojamaa See http://cygwin.com/ml/cygwin/2013-11/msg00464.html -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: mosh-1.2.4-1 (x86) missing mosh executable in package !
On 11/29/2013 02:38 AM, Egon Ojamaa wrote: https://sourceware.org/ml/cygwin/2013-11/msg00381.html I have tried several mirrors and i get no mosh or mosh.exe or any bash alias for mosh command. As I peek into binary package file.. I see there is only 2 files (mosh-client.exe,mosh-server.exe) , but the man page speaks of using "mosh" command. admin9000@Win764bitTestMachine~ $ mosh -bash: mosh: command not found admin9000@Win764bitTestMachine~ $ ls /usr/bin/mos* /usr/bin/mosh-client.exe /usr/bin/mosh-server.exe oops, I'll fix it ASAP admin9000@Win764bitTestMachine~ If i use x64 cygwin. Everything works fine. admin@T64TW7Poff ~ $ mosh Usage: /usr/bin/mosh [options] [--] [user@]host [command...] admin@T64TW7Poff ~ $ ls /usr/bin/mos* /usr/bin/mosh /usr/bin/mosh-client.exe /usr/bin/mosh-server.exe -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: mosh-1.2.4-1 (x86_64)
I've updated mosh on x86_64 to the latest version 1.2.4 also. See http://cygwin.com/ml/cygwin-announce/2013-11/msg00017.html for the 32 bit announcement -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: protobuf-2.5.0-1 (x86)
I've updated protobuf-2.5.0-1 on x86 only so far, with libprotobuf-devel and the new libprotobuf8, required by mosh. This is now the same version as on cygwinports. It is a feature release, adding support for "import public" and a new enum option "allow_alias" See http://protobuf.googlecode.com/svn/trunk/CHANGES.txt -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: mosh-1.2.4-1 (x86)
I've updated mosh on x86 to the latest version 1.2.4, x86_64 not yet. Changes largely include bug fixes, improved robustness, and added platform support. This reinstates the original perl wrapper, as the failing perl IO::Tty module is not used anymore. See http://mailman.mit.edu/pipermail/mosh-users/2013-March/000167.html -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Updated: make-4.0-1 (x86 and x86_64)
I'm very happy to have make-4.0, contrary to most other distros. make-4.0 fixed some crazy bugs I was chasing which appeared with make-3.81 -j4 and I was scratching my head for months. I even added .NOTPARALLEL: hints to no avail. v4 fixed it, so it was not my fault. Thanks! -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Broken symlinks in ed, pwget and perl?
On Tue, Jul 9, 2013 at 12:35 AM, Balaji Venkataraman wrote: > I see some broken symlinks in /usr in my install - AFAIK, in the > latest versions of these packages. Since I couldn't find any related > report, thought I'd report it. Not sure if the maintainers are already > aware of these. Noticed I have ed because of texlive-collection-basic. Thanks, I am aware of this one. It's harmless. > lrwxrwxrwx 1 user Users 26 Jul 17 2012 > /usr/lib/perl5/5.14/i686-cygwin-threads-64int/CORE/cygperl5_14_2.dll > -> /usr/bin/cygperl5 > _14_2.dll -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygutils Postinstall Script Errors With Exit Code 128
On Tue, May 28, 2013 at 2:43 Paul.Nickerson wrote: > I am attempting to install Cygwin, and am getting errors near the end of > the process. I am using version 2.774 of setup.exe on Microsoft Windows > Server 2003 R2 Datacenter x64 Edition Service Pack 2 and the default > Cygwin packages. This is an Amazon AWS EC2 instance, and I am remote > desktopping in. In the Cygwin Setup GUI, after it goes through the install > procedure, I get a window titled Postinstall script errors, with the below > output text: > > Package: base-cygwin > 000-cygwin-post-install.sh exit code 128 > Package: terminfo > terminfo.sh exit code 128 > Package: bash > bash.sh exit code 128 > Package: coreutils > coreutils.sh exit code 128 > Package: _autorebase > autorebase.bat exit code -1073741819 > Package: base-files > base-files-profile.sh exit code 2816 > base-files-mketc.sh exit code 128 > Package: cygutils > cygutils.sh exit code 127 > Package: man > man.sh exit code 128 I got the cygutils postinstall error also, caused by missing dependencies. $ cat /etc/postinstall/cygutils.sh /usr/bin/update-desktop-database /usr/bin/update-mime-database /usr/share/mime both scripts do not exist, and are no cygutils reqs. please test against it. like: test -f /usr/bin/update-desktop-database && /usr/bin/update-desktop-database test -f /usr/bin/update-mime-database && /usr/bin/update-mime-database /usr/share/mime > If I then open Cygwin Terminal using the Desktop shortcut, I get a window > titled "-sh" and a prompt that says "-sh-4.1$". The command "ls" returns > "-sh: ls: command not found", but echo works. I have tried re-running > setup.exe, removing the cygwin directory, re-downloading the setup.exe, > removing HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Cygwin from the registry, > setting "Turn on DEP for essential Windows programs and services only" and > rebooting, altering file and folder permissions, deleting the cache and > using different mirrors, and using rdesktop in CentOS vs. mstsc.exe in > Windows to remote desktop in, but none of this changes the behavior. > > I have an odd and possibly related behavior. If I open Command Prompt, run > C:\cygwin\bin\bash.exe --norc --noprofile > to get a "bash-4.1$" prompt, then in there run > if [ "foo" = "foo" ]; then echo "Expression evaluated as true."; fi > the bash prompt will exit back to command prompt, and %ERRORLEVEL% has > been set to 128. > Running that if statement in the window brought up by the Cygwin Terminal > Desktop shortcut will sometimes make the window close, but not always. I > have not explored how I might be triggering the Desktop shortcut to work > or not work. > > I have attached setup.log and setup.log.full. > > When I run cygcheck -s -v -r > cygcheck.out, it hangs and does not exit. > Checking Task Manager, I see that it's using ~45% CPU (I have 2 virtual > cores). It does write some things out to cygcheck.out, which I have > attached. When I run the command in Command Prompt without redirecting > output to a file, I get a little more information before it hangs, which I > have copied out of the command prompt and attached as > cygcheck-no-redirect.out. I do not know why it's saying I have multiple > cygwin1.dlls on my path. There is only C:\cygwin\bin\cygwin1.dll. > > Looking at cygcheck.out, I am running in a Terminal Service session, which > makes sense as I am remote desktopped in. My problem might be related to > FAQ #2.14 (http://cygwin.com/faq-nochunks.html#faq.setup.setup-fails-on-ts > ), but the DEP solution is not helping me. I tried running > "C:\cygwin\bin>peflags --tsaware=true --tsaware *" in Command Prompt, but > it did not change anything. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Were the Perl multithreading problems ever fixed?
On Mon, May 20, 2013 at 1:14 PM, KARR, DAVID wrote: > Last year I had reported some problems with a Perl script that utilizes > multithreading. I believe it was Reini Urban who told me that there were > known problems with Perl multithreading and that an ETA for a set of fixes > was not known yet. Does anyone know if those particular Perl multithreading > issues have been dealt with in later Cygwin releases? I'm still on 1.7.17. These were entirely perl related and not cygwin. And most of the known problems were fixed with the change from non-thread safe usemymalloc (perl internal malloc) to the thread-safe system malloc with 5.14.2. There are still minor thread problems within perl, but nothing dramatic. The upcoming 5.18.0 should have fixed more. Do you have a link to your report? So I can test it. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: clamav-0.97.8-1
I've updated clamav to the latest version 0.97.8 Release Notes 0.97.8: This release addresses several reported potential security bugs. 0.97.7: This is a bugfix release. See http://www.clamav.net/ or http://freecode.com/projects/clamav/ -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: the DBI for perl
On Sat, Mar 23, 2013 at 5:55 AM, Wynfield Henman wrote: > Thank you Csaba and Reini for the information in helping me build the > Perl database interface code. I downloaded the gcc-4 and the build > process worked. > And Reini, thanks for the 64 number significance explanation. And while we are here: I hope you are not using the unpatched cygwin DBI for any public facing server. DBI 1.624 still needs my use-after-free patch from https://github.com/rurban/distroprefs/blob/master/sources/authors/id/R/RU/RURBAN/patches/DBI-1.622_921.patch It's just cygwin, but who knows. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl (why 64int on 32int machine)
On Fri, Mar 22, 2013 at 6:48 AM, Wynfield Henman wrote: > I just downloaded and tried to build and install Perl's Database > Interface, DBI (yes the hard way, using Marefile.PL). > > Configure completed fine, but make fails with: > " make > gcc-4 -c-DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -g > -fno-strict-aliasing -pipe -fstack-protector -DUSEIMPORTLIB -O3 > -DVERSION=\"1.623\" -DXS_VERSION=\"1.623\" > "-I/usr/lib/perl5/5.14/i686-cygwin-threads-64int/CORE" -W -Wall > -Wpointer-arith -Wbad-function-cast -Wno-comment -Wno-sign-compare > -Wno-cast-qual -Wmissing-noreturn -Wno-unused-parameter Perl.c > /bin/sh: gcc-4: command not found > Makefile:625: recipe for target `Perl.o' failed" So you need to install gcc-4 > The above also mentions > "/usr/lib/perl5/site_perl/5.14/i686-cygwin-threads-64int" > which I do have on my system. I did not select it and I don't have a > 64 bit system. > Would this indicate a setup ini problem for perl? No, i686 is 32bit, optimized for i686. 64bit would be x86_64 -64int means that the internal int size is 8 byte and optimized for 64bit systems. but it works also on pure non-pentium 32bit intel CPUs. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Perl DBD::Oracle 'make test' fails: Oracle.dll permission denied
On Mon, Mar 4, 2013 at 1:01 PM, Bob McGowan wrote: > I have DBI 1.623 installed, and am attempting to install DBD::Oracle 1.27. > > I'm using Oracle instant client for Oracle 11.2, and I created my own > oci.def file using 'pexports' and 'dlltool', as described in the header of > the original oci.def file. > > The 'perl Makefile.PL' generates no errors. > > My 'make' creates Oracle.dll without any major issues (a few minor > complaints about mismatched types in printf, pointer casts, ...). > > The 'make test' fails the first test: > > Can't load ... Oracle.dll for module DBD::Oracle: Permission denied... I'm not sure if the Dynaloader fails, or if the connection to the oracle db fails with this error. If it's the Dynaloader be sure that all dependencies can be loaded. ldd blib/arch/Oracle/Oracle.dll will tell you that. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: wrong performance of malloc/free under multi-threading
ptmalloc3 would be even better. http://www.malloc.de/en/ -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Binutils objcopy bug (was Re: rebase segfault)
On Sat, Jan 26, 2013 at 1:52 AM, marco atzeri wrote: > On 1/26/2013 7:32 AM, Reini Urban wrote: >>> rebase is not to blame. I agree ;-) >>> Someone else is incorrectly managing the reloc table, >>> and also objcopy seems innocent ... >>> >>> Postgresql dll's are built in this way: >> >> >> My strong guess is dllwrap. >> No other packages uses the ancient dllwrap anymore. >> I tried to get rid of it, but got stuck somewhere else. >> > > Hi Reini, > I agree dllwrap seems the coolprit, and "gcc -shared" > seems a better alternative, at least on a single test with this dll. > > I looked on the postgresql makefiles and it is a big mess to > replace dllwrap; upstream is crazy, they crippled configure > forcing a specific version and refusing to use Automake. > > Autoconf+Automake will be a much cleaner approach, and will > allow to avoid at all the platform checks. Yes, I had the same impression but it is unfortunately not realistic. I worked against dllwrap removal but got stuck somewhere. When I find my old patches I'll hand it over to you. Just came back from holidays. > Could you make another check on 9.2.2 package before a new RFU > http://matzeri.altervista.org/cygwin-1.7/postgresql/ Sorry, holidays. Gold star please. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Binutils objcopy bug (was Re: rebase segfault)
On Fri, Jan 25, 2013 at 8:11 AM, marco atzeri wrote: > On 1/25/2013 4:00 PM, Corinna Vinschen wrote: >> >> On Jan 25 14:19, Kai Tietz wrote: >>> >>> 2013/1/25 marco atzeri : >>>> >>>> On 1/24/2013 11:00 AM, Corinna Vinschen wrote: >>>> >>>>> I already explained why: The SEGV happens during relocation. >>>>> The file header has been changed already. If you call the >>>>> same rebase, it will try to rebase the file to the same new >>>>> address. If current file base address == requested file base >>>>> address, rebase will return without performing any action. >>>>> >>>> >>>> Hi Corinna, >>>> I would like your opinion on this .reloc strange issue of >>>> dict_snowball, as I have the impression I found the root cause. >>>> [...] >>>> Questions: >>>> - Is it anomalous to have a .reloc portion addressing the >>>> debug_* sections (so the original build file is broken) >>>> - or should strip recognize and remove reloc portion not >>>> anymore relevant ? >>>> >>>> rebase is choking on this portion of the .reloc table >>>> >>>>> >>>>> Corinna >>>>> >>>> >>>> Thansk in advance >>>> Marco >>> >>> >>> Well, here are my 2-cents about that issue. In general it is a flaw >>> to have an base-relocation in debug-section, as this means such a >>> section can't be moved into a separate debug-file anymore, due that >>> has no relocation-information. >>> Nevertheless it would be good, if objcopy gets adjusted to eliminated >>> base-relocations of stripped sections. >> >> >> But the tool generating these debug relocs is gas, isn't it? Why >> on earth does it do that?!? >> >> I still think rebase is not to blame here. It has to assume that >> the relocation info is correct, doesn't it? > > > rebase is not to blame. I agree ;-) > Someone else is incorrectly managing the reloc table, > and also objcopy seems innocent ... > > Postgresql dll's are built in this way: My strong guess is dllwrap. No other packages uses the ancient dllwrap anymore. I tried to get rid of it, but got stuck somewhere else. > gcc -ggdb -O2 -pipe > -fdebug-prefix-map=/pub/devel/postgresql/postgresql-9.2.2-1/build=/usr/src/debug/postgresql-9.2.2-1 > -fdebug-prefix-map=/pub/devel/postgresql/postgresql-9.2.2-1/src/postgresql-9.2.2=/usr/src/debug/postgresql-9.2.2-1 > -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement > -Wendif-labels -Wmissing-format-attribute -Wformat-security > -fno-strict-aliasing -fwrapv -fexcess-precision=standard > -I/pub/devel/postgresql/postgresql-9.2.2-1/src/postgresql-9.2.2/src/include/snowball > -I/pub/devel/postgresql/postgresql-9.2.2-1/src/postgresql-9.2.2/src/include/snowball/libstemmer > -I../../../src/include > -I/pub/devel/postgresql/postgresql-9.2.2-1/src/postgresql-9.2.2/src/include > -c -o dict_snowball.o > /pub/devel/postgresql/postgresql-9.2.2-1/src/postgresql-9.2.2/src/backend/snowball/dict_snowball.c > > > dllwrap -o dict_snowball.dll --dllname dict_snowball.dll --def > libdict_snowballdll.def dict_snowball.o api.o utilities.o > stem_ISO_8859_1_danish.o stem_ISO_8859_1_dutch.o stem_ISO_8859_1_english.o > stem_ISO_8859_1_finnish.o stem_ISO_8859_1_french.o stem_ISO_8859_1_german.o > stem_ISO_8859_1_hungarian.o stem_ISO_8859_1_italian.o > stem_ISO_8859_1_norwegian.o stem_ISO_8859_1_porter.o > stem_ISO_8859_1_portuguese.o stem_ISO_8859_1_spanish.o > stem_ISO_8859_1_swedish.o stem_ISO_8859_2_romanian.o stem_KOI8_R_russian.o > stem_UTF_8_danish.o stem_UTF_8_dutch.o stem_UTF_8_english.o > stem_UTF_8_finnish.o stem_UTF_8_french.o stem_UTF_8_german.o > stem_UTF_8_hungarian.o stem_UTF_8_italian.o stem_UTF_8_norwegian.o > stem_UTF_8_porter.o stem_UTF_8_portuguese.o stem_UTF_8_romanian.o > stem_UTF_8_russian.o stem_UTF_8_spanish.o stem_UTF_8_swedish.o > stem_UTF_8_turkish.o -L../../../src/port -Wl,--allow-multiple-definition > -Wl,--enable-auto-import -L/usr/local/lib -Wl,--as-needed > -L../../../src/backend -lpostgres -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Rebuilding make
On Wed, Jan 9, 2013 at 7:02 AM, Fedin Pavel wrote: >> 1. doc/fdl.texi and doc/make-stds.texi files are missing from the archive. >> 2. configure seems to incorrectly determine HAVE_DOS_PATHS as true. This >> breaks $abspath() function. >> >> I solved (1) by adding these files from the original UNIX archive. Of >> course i can solve (2) by tweaking config/dospaths.m4, however perhaps i >> don't know something ? How do you build make ? > > Just FYI: i have tweaked dospaths.m4 and built a working make. After this i > successfully patched it to use spawn(). For benchmarking i used 'all' then > 'clean' targets on make's own source code. > --- cut --- > p.fedin@fedinw7x64 /usr/src/make-3.82.90-1 > $ time make.old > > [skip] > > real0m45.759s > user0m23.206s > sys 0m19.410s > > p.fedin@fedinw7x64 /usr/src/make-3.82.90-1 > $ time make.old clean > > [skip] > > real0m7.520s > user0m2.767s > sys 0m4.268s > > p.fedin@fedinw7x64 /usr/src/make-3.82.90-1 > $ time make > > [skip] > > real0m31.869s > user0m16.470s > sys 0m14.061s > > p.fedin@fedinw7x64 /usr/src/make-3.82.90-1 > $ time make clean > > [skip] > > real0m2.740s > user0m0.748s > sys 0m1.643s > > p.fedin@fedinw7x64 /usr/src/make-3.82.90-1 > $ > --- cut --- > 'clean' target runs especially faster, you see the difference with a naked > eye. I believe in case of gcc there's disk access factor. 0m45.759s+0m7.520s => 0m31.869s+0m2.740s Great! Can you gist the patches somewhere please? -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: postgres initdb: error while loading shared libraries: ?
On Wed, Jan 9, 2013 at 5:05 PM, Ryan Johnson wrote: > On 08/01/2013 11:43 PM, Ryan Johnson wrote: >> >> On 08/01/2013 9:20 PM, Yaakov (Cygwin/X) wrote: >>> >>> On Tue, 08 Jan 2013 20:44:10 -0800, Ryan Johnson wrote: >>>> >>>> The error message is: >>>>> >>>>> $ initdb -D /usr/share/postgresql/data >>>>> /usr/sbin/initdb.exe: error while loading shared libraries: ?: cannot >>>>> open shared object file: No such file or directory >>>> >>>> Any ideas? I can't reproduce it on my own machine. Running cygcheck on >>>> /usr/sbin/initdb give very normal-looking results, and BLODA checks are >>>> coming up empty. Is there something obviously wrong in my instructions? >>>> Or should I have them send their cygcheck output and let folks on the >>>> list try to diagnose the problem? >>> >>> cygcheck output would be helpful, as always, but my wild guess is that >>> they have the wrong, or more than one, libpq installed. If >>> I'm right, reinstalling libpq5 should fix this. >> >> ! >> >> I just checked the cygcheck output again and found this: >>> >>> cygcheck: track_down: could not find cygldap-2-3-0.dll >> >> >> Not sure how I missed seeing that before... >> >> cygcheck on my machine says the .dll belongs to libopenldap2_3_0-2.3.43-3; >> acursory check of setup.ini didn't turn up an obvious dependency listing. Is >> there a chance the dependency didn't get pulled in automatically like it >> should have? > > It turns out the 2_4_2 openldap package got pulled in instead of 2_3_0, but > pgsql wants the latter. I verified that my local install has the correct > (older) package and not the newer one. > > Thoughts? I'm tired of postgresql. Anyone wants to take over? Should build OOTB, but my improvements to the antique build system and ntlm auth never made it in. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Updated: perl-DBI-1.623-1
On Tue, Jan 8, 2013 at 10:35 PM, Yaakov wrote: > The following package has been updated in the Cygwin distribution: > > *** perl-DBI-1.623-1 > > The Perl Database Interface (DBI) provides a single API to access a wide > variety of databases, support for which is provided by a DBD::* driver > module (such as perl-DBD-mysql for MySQL servers). > > This is an update to the latest upstream release. Note: I strongly advise against the use of DBI-1.622 and 1.623 on public facing systems, because of https://rt.cpan.org/Ticket/Display.html?id=75614 This is the currently biggest known perl security problem, besides require "strict.pm\0shellcode"; and similar nul-char syscalls. Not that is likely that cygwin is used on public servers, but who knows... The patches are at also at https://github.com/rurban/distroprefs -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: clamav-0.97.6-1
I've updated clamav to the latest version 0.97.6 I've also added the 55K bytecode database file, but be sure to enable this option in /etc/freshclam.conf otherwise it will be deleted and will be downloaded again when you enable it there. If you enable the google safebrowsing database you will download 15M. Release Notes 0.97.6: A bug were CL_EFORMAT: Bad format or broken data ERROR was reported as the scan result was fixed. 0.97.5 (missed) This release addresses possible evasion cases in some archive formats (CVE-2012-1457, CVE-2012-1458, and CVE-2012-1459). It also addresses stability issues in portions of the bytecode engine. This release is recommended for all users. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Request for upgrade to clamav package
On Sun, Dec 23, 2012 at 3:52 PM, Jonathan D Johnston wrote: > Hello clamav maintainer, > > Often when I update my ClamAV database with freshclam (1), I get the > following message: > > WARNING: Your ClamAV installation is OUTDATED! > WARNING: Local version: 0.97.4 Recommended version: 0.97.6 > > Could the Cygwin clamav package be upgraded? Oops, I missed that. Thanks for the heads up. Will be uploaded shortly. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Strange and very annoying bug/problem with CPAN
On Sun, Dec 16, 2012 at 3:45 PM, pierre masci wrote: > Hi all, > CPAN does strange things here. > I installed Cygwin 1.7.17 on WinXP a few days ago, and am using Perl 5.14.2. > > Often when i'm installing a module from CPAN, it stops near the start > on an error, telling me that it "Couldn't move > $temporary_module_folder to $cpan_build_folder". I have put the > complete copy-pasted error below this text that explains the problem. > > The very strange thing is that it only does it "sometimes" (too > often), and it seems to be unpredictable : the same module will > sometimes start installing, and sometimes just die on this error 20 > times in a row; and then 10 minutes later it will work. > > It is extremely annoying : i start an install, stay for the first > minute just in case this error happens, then start to do other work > related tasks, and when i come back to it one of the dependencies has > failed with this error. And keep on failing for 10 minutes, until > suddenly it works. It takes me hours/days to install all the > dependencies of a single module that i need. And i have to keep on > checking every 5 minutes that the install hasn't been stopped. Or > sometimes realize after an hour that it had stopped after only 2 > minutes. > > If anybody has an idea, please help :-) > Pierre aka mascip I also sometimes get this error, and it's an upstream CPAN error with the unpacking logic. https://rt.cpan.org//Dist/Display.html?Queue=CPAN doesn't list it, though I remember having it reported some time ago. Please file a new report there, Andy will remember maybe. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Rebase/Perl packaging problem?
On Mon, Nov 26, 2012 at 5:21 PM, Buchbinder, Barry (NIH/NIAID) [E] wrote: > For me, this is only a problem because of the rebaseall error message. > (In other words, it is merely a slight annoyance.) I've no idea > whether this causes a problem for perl as I do not usually use perl > (at least directly). > > c:\cygwin\bin> dash -c rebaseall > /usr/lib/perl5/5.14/i686-cygwin-threads-64int/CORE/cygperl5_14_2.dll: skipped > because nonexistent. Yes, I know already. It will be fixed with the next update. But since 5.14.3 much is worse than 5.14.2 and all 5.16 releases are also not much better so far, I'll wait for the next good release upstream. The wrong symlink can be ignored, and you can delete it by yourself. There should be a symlink of /usr/lib/perl5/5.14/i686-cygwin-threads-64int/CORE/cygperl5_14.dll to /usr/bin/cygperl5_14.dll only. > /c> ls -og > /usr/lib/perl5/5.14/i686-cygwin-threads-64int/CORE/cygperl5_14_2.dll > lrwxrwxrwx 1 26 2012-10-22 15:00:36 > /usr/lib/perl5/5.14/i686-cygwin-threads-64int/CORE/cygperl5_14_2.dll -> > /usr/bin/cygperl5_14_2.dll > > /c> ls -og /usr/bin/cygperl5_14_2.dll > /bin/ls: cannot access /usr/bin/cygperl5_14_2.dll: No such file or directory > > Perhaps > > is meant to point to > and not to ? -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [mosh-devel] mosh 1.2.3 error when using on Cygwin
On Fri, Nov 9, 2012 at 4:10 PM, nyc4bos wrote: > [My cygcheck.out was somehow not included, so I am resending] > > Reini Urban writes: >> On 11/05/2012 06:47 PM, nyc4bos wrote: >>> After starting up mosh on Cygwin and then attempting to type >>> `ls', I see the following on my screen: >>> >>> $ ls select: No error >>> >>> >>> mosh did not shut down cleanly. Please note that the >>> mosh-server process may still be running on the server. >>> >>> [mosh is exiting.] >>>1 [main] mosh-client 4524 cygthread::detach: called detach but inuse >>> 0, th >>> read 0xF7C? >>> >>> >>> Sometimes I am able to type a few commands but mostly it is only >>> after one command before I see the "select: No error" message. >>> >>> The mosh-server.exe process is still running. >>> >>> I am on Windows XP and I am running a freshly installed Cygwin using >>> Cygwin setup 1.7.17-1 (the latest) and mosh 1.2.3. >>> >>> Thanks. I am afraid, I could not get any insight into your problem. The cygcheck looks fine I would check for windows unusual hooks in your system, like antivirus checkers or bloda. >> It looks like you are using mosh-1.2.2-1 (the perl wrapper) >> and not the latest version. If so, please upgrade your mosh to latest >> which is mosh-1.2.3-1 >> >> If not, please send us a the output of cygcheck -s -v -r > cygcheck.out >> as explained in http://cygwin.com/problems.html > > Owner@station03 ~ > $ which mosh > /usr/bin/mosh > > Owner@station03 ~ > $ mosh --version > mosh 1.2.3 > Copyright 2012 Keith Winstein > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>. > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > > Thanks. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [mosh-devel] mosh 1.2.3 error when using on Cygwin
On 11/05/2012 06:47 PM, nyc4...@aol.com wrote: After starting up mosh on Cygwin and then attempting to type `ls', I see the following on my screen: $ ls select: No error mosh did not shut down cleanly. Please note that the mosh-server process may still be running on the server. [mosh is exiting.] 1 [main] mosh-client 4524 cygthread::detach: called detach but inuse 0, th read 0xF7C? Sometimes I am able to type a few commands but mostly it is only after one command before I see the "select: No error" message. The mosh-server.exe process is still running. I am on Windows XP and I am running a freshly installed Cygwin using Cygwin setup 1.7.17-1 (the latest) and mosh 1.2.3. Thanks. It looks like you are using mosh-1.2.2-1 (the perl wrapper) and not the latest version. If so, please upgrade your mosh to latest which is mosh-1.2.3-1 If not, please send us a the output of cygcheck -s -v -r > cygcheck.out as explained in http://cygwin.com/problems.html Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html -- Reini Working towards a true Modern Perl. Slim, functional, unbloated, compile-time optimizable -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: catdoc-0.94.2-4 [SECURITY]
I've updated the catdoc package, which dumps Word, Excel and Powerpoint files contents. http://pkgs.fedoraproject.org/cgit/catdoc.git/plain/catdoc-0.94.2-bufferoverflow-rh872390-rh872391.patch Thanks Yaakov -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: A cygwin mosh question
On Thu, Nov 1, 2012 at 8:14 PM, Eliot Moss wrote: > On 11/1/2012 9:05 PM, Eliot Moss wrote: >> On 10/31/2012 1:46 PM, Eliot Moss wrote: >>> >>> After seeing the announcement on mosh, I decided to install it and >>> try it out. I installed it on a remote server running Red Hat style >>> Linux using yum, and on my laptop using cygwin. Sadly, I have run >>> into some problems: >>> >>> 1) The cygwin install does not include the dependency on the >>> IO:Tty package. I installed that manually, using cpan. Because I removed the perl wrapper, yes. >>> 2) When I try to mosh to my remote server, all I ever get is >>> "Hangup". Since there does not seem to be any "verbose mode", >>> I am not sure how to diagnose this further. >> >> I installed the latest version today and was able to get things >> working. (It prints out more about issues connecting, which >> allowed me to resolve them.) >> >> - The remote end was not setting LANG for UTF-8. I had to do this >>by: mosh --server='mosh-server new -l LANG=en_US.UTF-8' >> >> - I discovered that mosh does not support an xterm escape sequence >>that I use, namely one to *read* the window icon label: CSI 20 t >>and also CSI 11 t (reports whether the window is iconified). My >>main purpose is to save and use the icon label as the base for >>setting a longer label or title >> >> I have worked around this by setting an extra environment variable >> when using mosh, and skipping the reading of the icon label in that >> case. >> >> However, all of this is not really cygwin-specific, so I'll stop >> there. The LANG issue needs to be reported upstream, yes. The special icon getter, hmm. You can try to add a patch upstream for this weird use-case. >> However, the failure to install the IO:Tty dependency may be relevant. >> Is there an easy way I can test that again? What would I uninstall >> and reinstall to check? That is, cpan will install things, but how >> would I *un*-install IO:Tty to check whether cygwin install of mosh >> loads it? > > > Oh, I think I get it now, after digging further into what the install > of mosh actually does: the newer versions do not use perl, but work > directly -- is that right? If so, then the lack of dependence is > correct, and I apologize for the extra chatter! Yes. Perl caused problems in forks using IO::Pty and reading from STDIN. This was explained in the announcement of the experimental mosh-1.2.2-2 package. http://sourceware.org/ml/cygwin-announce/2012-07/msg00021.html -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problem with HTTPS in LWP module in Perl
On Thu, Nov 1, 2012 at 1:22 PM, Reini Urban wrote: > On Thu, Nov 1, 2012 at 1:05 PM, Björn Kautler wrote: >> I'm having a problem with https requests to >> "https://www.geocaching.com"; in perl. >> Nothing was done at all, then I found out I need to install >> LWP::Protocol:https which I did with "cpan LWP::Protocol:https". >> Now according to Wireshark at least SSL communication is started. >> But after the "Client Hello" it just hangs until a timeout happens, >> waiting for the "Server Hello". >> With other HTTPS pages like "https://www.google.com"; it works fine. >> The exact same Perl script works fine under Ubuntu. >> The https request to the same page works fine with curl under cygwin. >> If I change the SSL socket class to Net::SSL instead of >> IO::Socket::SSL, it also hangs after the "Client Hello", but then >> retries with SSLv3 instead of TLSv1 according to Wireshark and this at >> least works a bit better though not completely. >> So I guess something is weird in the Cygwin port of IO::Socket::SSL. :-/ > > Probably, but I cannot reproduce it. > If it is, you need to file a rt.cpan.org ticket for this, > with some wireshark loggings and the exact request. > > $ lwp-request https://www.geocaching.com/ > 501 Protocol scheme 'https' is not supported (LWP::Protocol::https not > installed) > $ cpan LWP::Protocol::https > ... (built and installed SULLR/IO-Socket-SSL-1.77.tar.gz, > GAAS/LWP-Protocol-https-6.03.tar.gz) > /usr/bin/make install -- OK > > $ lwp-request -USed https://www.geocaching.com/ > GET https://www.geocaching.com/ > User-Agent: lwp-request/6.03 libwww-perl/6.04 > > 500 Can't connect to www.geocaching.com:443 > Content-Type: text/plain > Client-Date: Thu, 01 Nov 2012 18:21:07 GMT > Client-Warning: Internal response > > From debian: > $ lwp-request -USed https://www.geocaching.com/ > GET https://www.geocaching.com/ > User-Agent: lwp-request/5.834 libwww-perl/6.04 > > GET https://www.geocaching.com/ --> 500 Can't connect to > www.geocaching.com:443 > Content-Type: text/plain > Client-Date: Thu, 01 Nov 2012 18:18:49 GMT > Client-Warning: Internal response > > $ lwp-request -USed https://www.google.com/ > -> 200 OK I got a bit more information from some other version: $ perl5.14.3 -S lwp-request -USed https://www.geocaching.com/ GET https://www.geocaching.com/ User-Agent: lwp-request/5.834 libwww-perl/6.04 GET https://www.geocaching.com/ --> 500 Can't connect to www.geocaching.com:443 (Crypt-SSLeay can't verify hostnames) Content-Type: text/plain Client-Date: Thu, 01 Nov 2012 18:22:57 GMT Client-Warning: Internal response So I think it's on the application level, not the library. This is with Crypt::SSLeay 0.64. My Cygwin has 0.60, and debian had 0.58. See http://stackoverflow.com/questions/12116244/https-proxy-and-lwpuseragent how to utilize PERL_LWP_SSL_VERIFY_HOSTNAME=0 -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problem with HTTPS in LWP module in Perl
On Thu, Nov 1, 2012 at 1:05 PM, Björn Kautler wrote: > I'm having a problem with https requests to > "https://www.geocaching.com"; in perl. > Nothing was done at all, then I found out I need to install > LWP::Protocol:https which I did with "cpan LWP::Protocol:https". > Now according to Wireshark at least SSL communication is started. > But after the "Client Hello" it just hangs until a timeout happens, > waiting for the "Server Hello". > With other HTTPS pages like "https://www.google.com"; it works fine. > The exact same Perl script works fine under Ubuntu. > The https request to the same page works fine with curl under cygwin. > If I change the SSL socket class to Net::SSL instead of > IO::Socket::SSL, it also hangs after the "Client Hello", but then > retries with SSLv3 instead of TLSv1 according to Wireshark and this at > least works a bit better though not completely. > So I guess something is weird in the Cygwin port of IO::Socket::SSL. :-/ Probably, but I cannot reproduce it. If it is, you need to file a rt.cpan.org ticket for this, with some wireshark loggings and the exact request. $ lwp-request https://www.geocaching.com/ 501 Protocol scheme 'https' is not supported (LWP::Protocol::https not installed) $ cpan LWP::Protocol::https ... (built and installed SULLR/IO-Socket-SSL-1.77.tar.gz, GAAS/LWP-Protocol-https-6.03.tar.gz) /usr/bin/make install -- OK $ lwp-request -USed https://www.geocaching.com/ GET https://www.geocaching.com/ User-Agent: lwp-request/6.03 libwww-perl/6.04 500 Can't connect to www.geocaching.com:443 Content-Type: text/plain Client-Date: Thu, 01 Nov 2012 18:21:07 GMT Client-Warning: Internal response From debian: $ lwp-request -USed https://www.geocaching.com/ GET https://www.geocaching.com/ User-Agent: lwp-request/5.834 libwww-perl/6.04 GET https://www.geocaching.com/ --> 500 Can't connect to www.geocaching.com:443 Content-Type: text/plain Client-Date: Thu, 01 Nov 2012 18:18:49 GMT Client-Warning: Internal response $ lwp-request -USed https://www.google.com/ -> 200 OK -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: A problem with perl and cygpixman-1-0.dll
On Wed, Oct 31, 2012 at 5:00 PM, marco atzeri wrote: > On 10/31/2012 10:24 PM, Zdzislaw Meglicki wrote: >> >>> funny, I build it but forgot and never installed. At least you can >> remove >>> the third one. >> >> Err... which is the third one? Let me list the three here and you tell me >> which >> can be removed: > > > to know if a file belongs to any package, use: > > cygcheck -f name_with_path > > $ cygcheck -f > /usr/lib/perl5/vendor_perl/5.14/i686-cygwin-threads-64int/auto/Graphics/Magick/Magick.dll > perl-Graphics-Magick-1.3.16-1 > > >> >> $ pwd >> /usr/lib/perl5 >> $ find . -name Magick.dll -print >> ./site_perl/5.14/i686-cygwin-threads-64int/auto/Image/Magick/Magick.dll >> >> ./vendor_perl/5.14/i686-cygwin-threads-64int/auto/Graphics/Magick/Magick.dll >> ./vendor_perl/5.14/i686-cygwin-threads-64int/auto/Image/Magick/Magick.dll >> $ >> >> Is the one in site_perl superfluous or the ones in vendor_perl? Will perl >> scripts >> automatically switch to the one left? > > I guess so No. You cannot just delete an shared perl library. If you delete ./site_perl/5.14/i686-cygwin-threads-64int/auto/Image/Magick/Magick.dll you also need to delete the according pm's, which are listed in the .packlist. Perl searches the @INC path for libraries. site_perl comes before vendor_perl. So if you delete ./site_perl/5.14/i686-cygwin-threads-64int/auto/Image/Magick/Magick.dll alone, your Image::Magic will be broken until you reinstall it via CPAN or delete totally via .packlist. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: A problem with perl and cygpixman-1-0.dll
On Wed, Oct 31, 2012 at 1:56 PM, Zdzislaw Meglicki wrote: >>> ./vendor_perl/5.14/i686-cygwin-threads- >>> 64int/auto/Image/Magick/Magick.dll > >> the other two are probably coming from your build, >> are the same or installed in different times ? > > I have by now overwritten my own installation with > the vanilla Cygwin perl-Image-Magick and > perl-Graphics-Magick. Good. > There should not be any non-Cygwin > stuff there. They both use the above Magick.dll, > don't they? No, they are totally different. They just have the same basename, by accident. > All three versions of Magick.dll are different. The other > two, the ones that live in vendor_perl have dates July 26 > and April 28. I have not been doing anything with them > at the time, so these must be some earlier versions > installed by Cygwin itself. I am surprised perl reinstall, > which I did recently, did not get rid of them. If you are not using any perl site_lib dlls, rebaseall is enough. If you are using perl site_lib dlls, you need to do perlrebase also. In your case you did not have perl-Image-Magick installed, you installed it seperately via CPAN into site_lib. This might create conflicts, if they are from different versions. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: mosh-1.2.3-1
I updated mosh to 1.2.3-1 on cygwin, which includes the previously experimental cxxwrapper for /usr/bin/mosh.exe as described in http://sourceware.org/ml/cygwin-announce/2012-07/msg00021.html This maintenance release makes a number of improvements to mosh 1.2.2 to improve speed, robustness, and security. It includes new implementations of AES and OCB that are more resilient to possible timing leakage and adds support for Solaris, licensing compatibility with Apple's iOS, and power-saving improvements to benefit the Android client. * Missing features: * --predict=experimental mode to local echo not yet implemented * Detect bogus MOSH_IP earlier is not yet implemented. * Security improvements: * Use OpenSSL AES implementation * Update AES-OCB implementation (Keegan McAllister) * Don't let bad server dictate IP (Felix Groebert) * New features: * Client hops ports to survive challenging client-side firewall * Server stops sending to save client power (Daniel Drown) * Set DiffServ code point and ECN-capable (Dave Täht) * Slow down if explicit congestion notification received * Warn about unattached Mosh sessions on login * Compatible with KDE konsole (uses BEL to terminate OSC) * Improved heuristic about color of predicted characters * Bug fixes: * Improved performance on systems with expensive time * No longer choke on "::" address for hosts with IPv6 * More conservative MTU and datagram sizing * Platform support: * Build on Solaris and IllumOS (Timo Sirainen, Ira Cooper) * Build on ARM with gcc 4.7 (Alexander Chernyakhovsky) * Licensing changes: * Allow distribution on Apple App Stores * Allow linking with OpenSSL mosh 1.2.3 is backwards-compatible with mosh clients back to 0.96 and mosh servers back to 1.0.9. Please let us know of any problems (https://github.com/keithw/mosh/issues). Best regards from the Mosh team, -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [RFE][PATCH] cygport: allow for subdirectory specification via CPAN_AUTHOR
On 09/26/2012 06:51 AM, Achim Gratz wrote:
Hi Yaakov,
several Perl distributions have chosen to put the actual archives in a
subdirectory (e.g. Inline::Files). So far I've dealt with those by editing
SRC_URI after "inherit perl", but I'd like something more straigtforward. I
propose that CPAN_AUTHOR should optionally include this additional subdirectory
as a "/subdir" suffix. Patch to that effect:
Just for easier understanding:
How would that look like for e.g.
A/AM/AMBS/Inline/Inline-Files-0.68.tar.gz
NAME=Inline-Files
inherit perl
CPAN_AUTHOR=AMBS/Inline
Looks a bit weird. Don't we have a better field for this cpan quirks?
Like a new CPAN_DIR which defaults to CPAN_AUTHOR?
Support subdirectories in CPAN download URL
* cygclass/perl.cygclass: Allow CPAN_AUTHOR to have a /subdir suffix.
This is necessary for some modules that put the distribution files
in some subdirectory. Only upcase the actual author name (up until
the first "/") and preserve case for the suffix part.
Modified cygclass/perl.cygclass
diff --git a/cygclass/perl.cygclass b/cygclass/perl.cygclass
index b4aecdf..4dbe824 100644
--- a/cygclass/perl.cygclass
+++ b/cygclass/perl.cygclass
@@ -139,9 +139,12 @@ HOMEPAGE="http://search.cpan.org/dist/${ORIG_PN}/";
# SEE ALSO
# mirror_cpan
#
-cpan_author_ftp=${CPAN_AUTHOR^^}
-SRC_URI="mirror://cpan/authors/id/${cpan_author_ftp:0:1}
/${cpan_author_ftp:0:2}/${cpan_author_ftp}
/${ORIG_PN}-${PV}.${CPAN_TARBALL_SUFFIX:-tar.gz}"
+cpan_author_ftp="${CPAN_AUTHOR%%/*}"
+cpan_module_ftp="${CPAN_AUTHOR#${cpan_author_ftp}}"
+cpan_author_ftp="${cpan_author_ftp^^}"
+SRC_URI="mirror://cpan/authors/id/${cpan_author_ftp:0:1}
/${cpan_author_ftp:0:2}/${cpan_author_ftp}$cpan_module_ftp
/${ORIG_PN}-${PV}.${CPAN_TARBALL_SUFFIX:-tar.gz}"
unset cpan_author_ftp
+unset cpan_module_ftp
fi# defined CPAN_AUTHOR
(Watch for the linewrap)
Regards,
Achim
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: peflags makes perl not print to stdout
On 09/27/2012 09:14 AM, Saurabh T wrote: Hi, I asked this before and havent gotten a reply. Is there any other information I can provide? This is currently quite a bummer for me. Any help will be greatly appreciated. Thanks. From: saurabh To: cygwin Subject: peflags makes perl not print to stdout Date: Mon, 24 Sep 2012 17:29:42 + I have been trying to get perl to use 2GB of memory (this is on a 32 bit xp machine with 4 GB total memory). As per http://cygwin.com/cygwin-ug-net/setup-maxmem.html I tried peflags --cygwin-heap=2048 /usr/bin/perl However this causes perl to not write to screen. On further investigation, I found the magic number to be 1040: $ peflags --cygwin-heap=1039 /usr/bin/perl /usr/bin/perl: initial Cygwin heap size: 1039 (0x40f) MB $ perl -e 'print "Hello\n";' Hello $ peflags --cygwin-heap=1040 /usr/bin/perl /usr/bin/perl: initial Cygwin heap size: 1040 (0x410) MB $ perl -e 'print "Hello\n";' In other words, anything 1040 and above, perl stops writing to screen. I have the latest cygwin (1.7.16) and perl (5.14.2). Any idea what might be wrong? Thank you. Yes, strange. I'm not aware of any heap magic or IO limits within perl. (contrary to clisp or other binaries using a copying gc). It's pure malloc, and it memory and io is purely dynamic. If cgf has no idea either you need to ask that on p5p. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl-5.14.2-3 installs broken symlinks
On Thu, Sep 27, 2012 at 5:26 AM, Steven Hartland wrote: > The following are dangling symlinks after a clean cygwin install updated > today. > /lib/perl5/5.14/i686-cygwin-threads-64int/CORE/cygperl5_14_2.dll > /usr/lib/perl5/5.14/i686-cygwin-threads-64int/CORE/cygperl5_14_2.dll > > $ cygcheck -p cygperl5_14_2.dll > Found 1 matches for cygperl5_14_2.dll > perl/perl-5.14.2-3 Larry Wall's Practical Extracting and Report Language Yes, I already know since every rebase prints this warning. It's just a packaging artefact, does no harm and will be fixed in the next update. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl: inconsistent archname in build config?
On Fri, Sep 7, 2012 at 8:30 PM, bert Dvornik wrote: > Summary: Cygwin's perl 5.14 uses cygwin-thread-multi-64int as the > archname for user module directories (i.e. those based on PERL5LIB), > but i686-cygwin-threads-64int as the archname for system module > directories and for installing files via cpan. This seems to be based > on the build configuration (there are two settings in different > places). It doesn't make sense to me, though maybe I'm missing > something. > > Long version: > > I ran into a problem with local module paths after updating to > perl-5.14.2-3. I usually install Perl modules locally into > ~/perl-lib/ by setting the prefix via CPAN's makepl_arg and > mbuildpl_arg configuration options. Then I can set my PERL5LIB to get > that installation tree automatically used by perl. > > This worked fine up to and including perl 5.10. But with 5.14 > something strange started happening. If I look at the @INC in the > "perl -V" output, I see this: > > Summary of my perl5 (revision 5 version 14 subversion 2) configuration: > [...lots of verbiage removed; see below for full output...] > %ENV: > > PERL5LIB="/home/bert/perl-lib/lib/perl5:/home/bert/perl-lib/lib/perl5/site_perl/5.14:/home/bert/perl-lib/lib/perl5/5.14" > @INC: > /home/bert/perl-lib/lib/perl5/cygwin-thread-multi-64int > /home/bert/perl-lib/lib/perl5 > /home/bert/perl-lib/lib/perl5/site_perl/5.14/cygwin-thread-multi-64int > /home/bert/perl-lib/lib/perl5/site_perl/5.14 > /home/bert/perl-lib/lib/perl5/5.14/cygwin-thread-multi-64int > /home/bert/perl-lib/lib/perl5/5.14 > /usr/lib/perl5/site_perl/5.14/i686-cygwin-threads-64int > /usr/lib/perl5/site_perl/5.14 > /usr/lib/perl5/vendor_perl/5.14/i686-cygwin-threads-64int > /usr/lib/perl5/vendor_perl/5.14 > /usr/lib/perl5/5.14/i686-cygwin-threads-64int > /usr/lib/perl5/5.14 > /usr/lib/perl5/site_perl/5.10 > /usr/lib/perl5/vendor_perl/5.10 > /usr/lib/perl5/site_perl/5.8 > . > There are two odd things about this. First, the @INC directories from > PERL5LIB use cygwin-thread-multi-64int, but the system ones use > i686-cygwin-threads-64int. Second, when CPAN installs packages, they > go into i686-cygwin-threads-64int, which is why the ones in my > perl-lib directory are not being found in @INC. > > Looking more closely at the output of "perl -V", I can see what's > probably causing the confusion: > > Summary of my perl5 (revision 5 version 14 subversion 2) configuration: > > Platform: > osname=cygwin, osvers=1.7.15(0.26053), > archname=cygwin-thread-multi-64int > uname='cygwin_nt-5.1 winxp 1.7.15(0.26053) 2012-05-09 10:25 i686 cygwin > ' > config_args='-de -Dlibperl=cygperl5_14.dll -Dcc=gcc-4 -Dld=g++-4 > -Darchname=i686-cygwin-threads-64int -Dmksymlinks -Dusethreads > -Accflags=-g' > > So the platform settings have "archname=cygwin-thread-multi-64int", > but config_args include "-Darchname=i686-cygwin-threads-64int". (Is > config_args the arg list passed to the "sh Configure" when building > perl? If so, shouldn't -Darchname ACTUALLY set the archname? Or is > there some other weirdness going on here?) Very interesting catch, thank you! I will need to think a bit how to fix this, not to break too much. Or if it needs t be fixed at all. EU::MM seems to work okay, just MB and local::lib seems to be affected. Yes, config_args is the cmdline, but archname is overridden elsewhere in the old Configure system, most likely the hints. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl man pages not working.
On Tue, Sep 4, 2012 at 8:11 PM, Larry Hall (Cygwin) wrote: > On 9/4/2012 4:07 PM, Erwin Waterlander wrote: >> I have installed the perl man pages via setup.exe, but they don't work: >> >> $ man perl >> No manual entry for perl >> >> It seems they are not there, while setup.exe says I have installed >> perl_manpages version 5.14.2-3. >> >> $ ls /usr/share/man/*/perl* >> ls: cannot access /usr/share/man/*/perl*: No such file or directory >> >> Also a reinstall via setup.exe does not help. > > > The man pages are there. See the list of those installed here: > > <http://cygwin.com/cgi-bin2/package-cat.cgi?file=perl_manpages%2Fperl_manpages-5.14.2-3&grep=perl_manpages> > > But it does look like there are some key ones missing in 5.14.2 (such > as perl.1). Oops, blush. Thanks for the report -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Perl 5.14 and XML::Parser
On Thu, Aug 16, 2012 at 6:55 AM, Christopher Faylor wrote: > On Wed, Aug 15, 2012 at 10:04:48PM -0600, Thomas Wicklund wrote: >>The update of perl on to 5.14 moved some perl modules to a new >>perl_vendor package which is not installed by default. The >>announcement I found stated that perl_vendor is modules "which are >>mainly required to build and test and report test results of other CPAN >>modules." That was the short summary, yes. >>I find that the XML::Parser module (at least) has been moved. I've >>been using this module for years to parse XML output for a set of >>Subversion tools. I had a couple hours of digging today to figure out >>why a coworker started getting errors after updating Cygwin, then >>figuring out the new package. As an request from Yaakov and also from upstream p5p I have moved all non-core packages to the new perl_vendor. >>As an occasional user of perl I would much prefer that the maximum >>number of packages be included in the distribution (since disk space >>and bandwidth are constantly becoming cheaper) than to have to spend >>time figuring out why something can't be found. This is right. I really sympathize with you and all others. But unfortunately I had to made this move for political reasons, not technical ones. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Perl 5.14.2 seems to expect gcc-4
On Thu, Aug 2, 2012 at 2:46 PM, Achim Gratz wrote: > Reini Urban writes: >> Please don't spread fud. Self-compiled cpan packages are always >> favored over vendor packages. See your @INC. > > I really meant packages, of the Cygwin variant (I've got cygport > definitions for all of them and posted a link to them over in > cygwin-apps). Managing dependencies with an opaque blob like > perl_vendor seemed more trouble than creating some 240 or so packages > that include all that are in perl_vendor, but one package for each > distribution (and an umbrella package for installing them all in one > go). I would be happy to assign it over to you if you are happy with it. I have no time to maintain hundreds of packages which change monthly. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Perl 5.14.2 seems to expect gcc-4
On Thu, Aug 2, 2012 at 1:08 PM, Achim Gratz wrote: > Aaron Schneider writes: >> Since a lot of people are having issues because 'perl_vendor' is not >> installed when should, wouldn't be better to set perl_vendor as a >> mandatory dependency of perl so just everyone gets it installed? I >> guess package size won't be an issue. > > No, please don't — I have compiled my own perl packages and need > perl_vendor to stay out of the way. If anything this would be a hint > that hiding packages in perl_vendor, while helping to keep the number of > packages down, doesn't help people finding what they need. Please don't spread fud. Self-compiled cpan packages are always favored over vendor packages. See your @INC. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Perl 5.14.2 seems to expect gcc-4
On Wed, Aug 1, 2012 at 5:14 PM, Aaron Schneider wrote: > On 01/08/2012 19:46, Reini Urban wrote: >> On Wed, Aug 1, 2012 at 10:46 AM, Matt Seitz (matseitz) wrote: >>> >>> Did Cygwin "setup.exe" prompt you to install the "gcc-4" package when you >>> updated perl? >>> >>> I thought "setup.exe" would prompt the user if any additional packages >>> needed to be installed. >> >> >> no. gcc-4, make and more are not automatically installed with perl. >> you will only need when you compile your own XS packages with cpan. >> >> XML::LibXML is included in the new package perl_vendor >> > > Since a lot of people are having issues because 'perl_vendor' is not > installed when should, wouldn't be better to set perl_vendor as a mandatory > dependency of perl so just everyone gets it installed? I guess package size > won't be an issue. Sure. But Yakoov explicitly wanted a perl independent from perl_vendor. Yakoov? -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Perl 5.14.2 seems to expect gcc-4
On Wed, Aug 1, 2012 at 10:46 AM, Matt Seitz (matseitz) wrote: >> On Wed, Aug 1, 2012 at 11:12 AM, Nikolai Weibull wrote: >> > >> > Cygwin updated perl to 5.14.2 on my system and now I can’t compile >> > XML::LibXML. It seems that >> > >> > c:\lib\perl5\5.14\i686-cygwin-threads-64int\Config.pm >> > >> > expects cc to be gcc-4. Gcc-4 doesn’t exist yet, it seems. What’s >> > going on here? >> >> Sorry, scratch that, gcc-4 is available. I got confused by the separate >> version schemes (which I realize are necessary, but easy to miss when >> you’re a bit stressed out.) > > Did Cygwin "setup.exe" prompt you to install the "gcc-4" package when you > updated perl? > > I thought "setup.exe" would prompt the user if any additional packages needed > to be installed. no. gcc-4, make and more are not automatically installed with perl. you will only need when you compile your own XS packages with cpan. XML::LibXML is included in the new package perl_vendor -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Rebase: still struggling with it
On Tue, Jul 31, 2012 at 4:44 AM, Charles Smith wrote: > $ /bin/rebaseall > /usr/lib/perl5/5.14/i686-cygwin-threads-64int/CORE/cygperl5_14_2.dll: skipped > because nonexistent. And this is caused by a minor perl packaging problem. You can simply ignore this warning. I'll fix it with the next perl update. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: sshd crashing
On Mon, Jul 30, 2012 at 5:50 PM, Pawel Jasinski wrote: > checking for gcc... gcc > checking whether the C compiler works... no > configure: error: in `/usr/src/openssh-6.0p1-2/build': > configure: error: C compiler cannot create executables > See `config.log' for more details > *** ERROR: configure failed > > If I look at config,log the things look funny around gcc invocation, > but I am kind of novice to cygport and can not figure out what's going > on: > > gcc -ggdb -O2 -pipe > -fdebug-prefix-map=/usr/src/openssh-6.0p1-2/build=/usr/src/debug/openssh-6.0p1-2 > -fdebug-prefix-ma > p=/usr/src/openssh-6.0p1-2/src/openssh-6.0p1=/usr/src/debug/openssh-6.0p1-2 > conftest.c >&5 > cc1: error: unrecognized command line option > "-fdebug-prefix-map=/usr/src/openssh-6.0p1-2/build=/usr/src/debug/openssh-6.0p1-2" > cc1: error: unrecognized command line option > "-fdebug-prefix-map=/usr/src/openssh-6.0p1-2/src/openssh-6.0p1=/usr/src/debug/openssh-6.0 > > What am I missing? You are using gcc (version 3) and not gcc4. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: install package from cpan report "address space needed by ... is already occupied"
On Fri, Jul 27, 2012 at 5:20 AM, Aaron Schneider wrote: > On 25/07/2012 3:13, ping wrote: >> >> I'm trying to install App::Asciio in cygwin, but got following error, >> please advice, or what info are still needed to proceed, thanks! >> >> CPAN: Module::Build loaded ok (v0.3613) >> >>CPAN.pm: Going to build N/NK/NKH/App-Asciio-1.02.71.tar.gz >> >>0 [main] perl 6432 child_info_fork::abort: address space needed >> by 'Base64.dll' (0xC6) is already occupied >>1 [main] perl 3844 child_info_fork::abort: unable to remap >> Util.dll to same address as parent (009A) - try running rebaseall >>0 [main] perl 10708 child_info_fork::abort: address space needed >> by 'Base64.dll' (0xC6) is already occupied >>0 [main] perl 11276 child_info_fork::abort: unable to remap >> Util.dll to same address as parent (009A) - try running rebaseall >>0 [main] perl 1976 child_info_fork::abort: address space needed >> by 'Base64.dll' (0xC6) is already occupied >> > > Could you rename your c:\cygwin folder to c:\cygwin_bak and try a fresh > install and see if happens the same? Are you installing cpan modules from > binaries or compiling them with 'perl Build.PL'? > > - There should be no need to rebase any dll, try installing all cpan modules > from source code (the tar.gz). Install only perl from cygwin's setup.exe. If > there are any compilation issues with any cpan module you will see it right > away. All modules should compile and pass all t tests. You will need to > install dependencies like gcc, gcc4, libbz2-devel, pkg-config and probably > more from setup.exe. > - Remember to keep closed all terminals and cygwin sessions when running > setup.exe > - I wasn't able to compile a lot of cpan modules under cygwin, for example > P/PD/PDENIS/Test-Strict-0.14.tar.gz with either perl 5.10 or perl 5.14. This > is not the case for Ubuntu, for example, at least trying to install all cpan > dependencies for App-Asciio-1.02.71. This part is a problem of a wrong test in Test-Strict-0.14/t/01all.t. It falsely assumes cygwin is MSWin32 because Win32 is loadable and then tries to convert paths by Win32::GetLongPathName(). Expand the attached two files into .cpan/ to apply my patch automatically on your next cpan attempt. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ Test-Strict-0.14.tar.gz Description: GNU Zip compressed data -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: sshd crashing
On Fri, Jul 27, 2012 at 4:44 PM, Pawel Jasinski wrote: > I have a fresh installation of cygwin on xp and win7 (both run 1.17.16-1). > I have run ssh-host-config followed by rebaseall. The CYGWIN variable > for sshd is not set. > I have tried with and without priv. separation. > It is started with cygrunsrv -S sshd > I can connect with ssh localhost. Things are ok until I do vi > /etc/profile. At this moment it crashes. > > Now if I try the version without priv separation to start by hand: > /usr/sbin/sshd -D -d -e things go well and it does not crashes when in > ssh session /etc/profile is edited. > Am I missing something in config? Inspect /var/log/sshd.log for obvious rebase errors and run rebaseall then. I fixed the same problem this way. > sshd: PID 484: service `sshd' failed: signal 11 raised -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Maxima can't write to /dev/stdout
On Thu, Jul 26, 2012 at 2:10 PM, Achim Gratz wrote:
> Reini Urban writes:
>> But note that clisp already should come with debug info.
>
> Where to look for it? I'm assuming that I need to step into the open
> function from the lisp "open" call via gdb to see where the trailing
> "/1" gets stripped of from the file name pointed to by the symlink, so
> I'd need to have at least a symbol file with that entry point.
Don't know yet. I'm still busy at work.
>> -g is required for the (disassemble) function to work.
>
> You mean in CFLAGS for the build?
Yes, and
src_install() {
# do not strip for (disassemble)
_CYGPORT_RESTRICT_strip_=1
--
Reini Urban
http://cpanel.net/ http://www.perl-compiler.org/
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Maxima can't write to /dev/stdout
On Thu, Jul 26, 2012 at 12:57 PM, Achim Gratz wrote: > Corinna Vinschen writes: >> If you can nail that down to the actual calls and decisions clisp is >> doing, it might help to find the cause. > > I'm trying to, but it seems I still miss some dependencies to actually > build clisp with debug information. Unfortunately the build is > structured in a way that it tells you each missing dependency piecemeal > after an ever increasing amount of stuff that it actually succeeded > building. Right now it seems that it specifically wants BDB 4.5 rather > than 4.8 even though configure said earlier it found BDB... I'll get > there eventually, just not as fast as I had hoped for. Agreed. But note that clisp already should come with debug info. -g is required for the (disassemble) function to work. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Irssi returns error message after Perl update
On Mon, Jul 23, 2012 at 11:14 AM, Sean Murphy wrote: > On Mon, Jul 23, 2012 at 12:30 AM, Reini Urban wrote: >> >> You have three possibilities. >> >> Install perl 5.10 from the tarball in parallel as explained in the >> 5.14 announcement, >> or bug the irssi maintainer to update irssi, >> or go back to perl 5.10 > > After spending some time with this over the rest of the weekend, I > came to the same conclusions. > > I don't want to be a pain, so I think I'll let the irssi maintainer > get to it at their own pace. I will, however, > attempt to install 5.10 in parallel as you suggest. I'd rather have > the updated version of perl, as I've just > installed mosh, and mosh will not operate with the older perl package. Then you can also try the experimental mosh-1.2.2-2 which is a 1.3 pre-release and does not use perl anymore: http://cygwin.com/ml/cygwin-announce/2012-07/msg00021.html -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: No DBI module when installing Perl 5.14
On Mon, Jul 23, 2012 at 9:32 AM, Andrew DeFaria wrote:
> I recently updated my Cygwin to 1.7.16. With this came Perl 5.14.2. While
> the update when fine, after updating I restarted a service that I wrote in
> Perl that used DBI. To my surprise it failed saying it couldn't find the DBI
> module. I used cpan to reinstall it but I was wondering if it was
> intentional that DBI would be missing after upgrading to 5.14.2.
DBI also did not come with perl-5.10, you installed it by yourself.
Check my update recipe from the announcement mail:
http://cygwin.com/ml/cygwin-announce/2012-07/msg00011.html
Update recommendations from 5.10:
--
Since 5.14 is not installed in parallel to 5.10, all your old 5.10 binary XS
modules will need to be reinstalled for 5.14.
BEFORE INSTALLATION of this 5.14
# get the list of your installed 5.10 modules
$ perl -MExtUtils::Installed \
-e'print join("\n", new ExtUtils::Installed->modules)' > module.list
AFTER INSTALLATION of 5.14
# install all previous modules for 5.10 and older
$ cpan `cat module.list`
PS: doing the cpanm dance with xargs is not recommended as it forks too much.
$ perl -MExtUtils::Installed \
-e'print join("\n", new ExtUtils::Installed->modules)' | xargs cpan
--
Reini Urban
http://cpanel.net/ http://www.perl-compiler.org/
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Irssi returns error message after Perl update
On Sat, Jul 21, 2012 at 2:47 PM, Sean Murphy wrote: > After recently updating Perl to the most recent version (5.14.2-3), > I've noticed that Irssi (0.8.15-2) will return > the following error message: > > /usr/bin/irssi.exe: error while loading shared libraries: > cygperl5_10.dll: cannot open shared object file: No such file or > directory You have three possibilities. Install perl 5.10 from the tarball in parallel as explained in the 5.14 announcement, or bug the irssi maintainer to update irssi, or go back to perl 5.10 -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: length in gawk returns wrong value
On Thu, Jul 19, 2012 at 12:02 PM, Eric Blake wrote: > On 07/19/2012 10:53 AM, Aaron Schneider wrote: >> I can't find such csh or cshell on my system, I've searched from >> packages and I only see scsh, slsh, posh, mosh, tcsh, zsh, mksh that I > > Both scsh and tcsh are from the csh family of shells. > > posh, zsh, mksh, bash, dash, and ksh are from the Bourne family of shells > > No idea what slsh or mosh are No login shells. mosh is a a remote shell, a better ssh for slow or varying connections. http://mosh.mit.edu/ slsh is the S-Lang shell. A different beast. http://www.jedsoft.org/slang/doc/html/slang-2.html#ss2.1 -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: mosh-1.2.2-2 (experimental)
For those who have problems with mosh to connect from cygwin to hosts which require ssh client keyboard interaction (host keys, yes/no, passphrase) I've uploaded an experimental build using this branch: https://github.com/piannucci/mosh/tree/patch-3 /usr/bin/mosh in perl is gone, there's now a mosh.exe for the frontend client. Missing features: --predict=experimental mode to local echo not yet implemented Detect bogus MOSH_IP earlier is not yet implemented. See http://blogs.perl.org/users/rurban/2012/07/i-had-to-remove-perl-from-mosh.html -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] New packages: mosh, protobuf, perl-Io-Tty
mosh has been uploaded to cygwin. The mosh people are now happy to point their windows folks over here. Oh my :) See http://mosh.mit.edu/ "New remote terminal application that allows roaming, supports intermittent connectivity, and provides intelligent local echo and line editing of user keystrokes. Mosh is a replacement for SSH. It's more robust and responsive, especially over Wi-Fi, cellular, and long-distance links." The necessary deps are protobuf and perl-IO-Tty. protobuf existed before in cygwinports and has been moved over to cygwin. Thanks Yaakov! http://code.google.com/p/protobuf/ "Protocol Buffers are a way of encoding structured data in an efficient yet extensible format. Google uses Protocol Buffers for almost all of its internal RPC protocols and file formats." libprotobuf-devel contains /usr/bin/protoc, the compiler. perl-IO-Tty is just the IO::Tty perl cpan module from my fellow coworker toddr. Hi Todd! New packages: * mosh-1.2.2-1 * libprotobuf7-2.4.1-1 * libprotobuf-devel-2.4.1-1 * perl-IO-Tty-1.10-1 -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygheap base mismatch detected
On Tue, Jul 17, 2012 at 9:37 PM, Andrew DeFaria wrote: > On 7/17/2012 6:56 PM, Reini Urban wrote: >> On Tue, Jul 17, 2012 at 7:02 PM, Andrew DeFaria wrote: >>> >>> Is there a workaround for the problem mentioned in >>> http://cygwin.com/ml/cygwin/2006-11/msg00580.html? I suddenly started >>> getting this error like every other time I run perl. >> >> perlrebase > > When I run perlrebase I get: > > Ltsdo-adefaria:perlrebase > 3 [main] perl5.10.1 (6808) C:\Cygwin\bin\perl5.10.1.exe: *** fatal > error - cygheap base mismatch detected - 0x612768B0/0xD268B0. > This problem is probably due to using incompatible versions of the cygwin > DLL. > Search for cygwin1.dll using the Windows Start->Find/Search facility > and delete all but the most recent version. The most recent version > *should* > reside in x:\cygwin\bin, where 'x' is the drive on which you have > installed the cygwin distribution. Rebooting is also suggested if you > are unable to find another cygwin DLL. > > and proceeds to consume about 10% of CPU for like 10 minutes. Am I just > supposed to let it crank along? No. This looks like you really got 2 cygwin1.dll's running. Strange. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygheap base mismatch detected
On Tue, Jul 17, 2012 at 7:02 PM, Andrew DeFaria wrote: > Is there a workaround for the problem mentioned in > http://cygwin.com/ml/cygwin/2006-11/msg00580.html? I suddenly started > getting this error like every other time I run perl. perlrebase -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Perl 5.14.2-3 doesn't include Term::ReadKey
On Mon, Jul 16, 2012 at 10:59 PM, Erik Falor wrote: > Perl 5.14.2-3 is shipping without the non-core Term::ReadKey module. > It seems that this module was left out once before and re-added in > 5.10: > http://sourceware.org/ml/cygwin/2008-07/msg00085 You need to install the seperate package perl_vendor. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Update: perl-5.14.2-3 and most perl dependencies
On Mon, Jul 16, 2012 at 2:58 AM, marco atzeri wrote: > On 7/16/2012 9:35 AM, Achim Gratz wrote: >> There seems to be a minor packaging error: >> /usr/lib/perl5/5.14/i686-cygwin-threads-64int/CORE/cygperl5_14_2.dll >> is a symbolic link pointing to >> /usr/bin/cygperl5_14_2.dll >> but this file doesn't exist. Thanks. It's a build script error, but harmless. I'll fix it with the next update. > I had the impression that symbolic link of dll does not work on cygwin > due to MS constrain Yes, but I use it the other way. The MS loader picks up the dll in /usr/bin because it's in the PATH, and cygwin gcc / ld (the linker) picks up the symlink in /CORE, where it is expected. This way I get around the import lib in most cases and can support multiple perl variants without name conflicts. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Update: More perl-5.14 package updates, subversion, {Image,Graphics}Magick, libproxy
I also moved the test versions of the following packages to current to work together with perl-5.14: perl-Net-Libproxy 0.4.7-2 subversion 1.7.5-4 ImageMagick 6.7.6.3-2 GraphicsMagick 1.3.15-2 Now only postgresql and ming is missing. Note: I haven't yet deleted any outdated package binaries. I will do it in about two days. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Update: perl-5.14.2-3 and most perl dependencies
14/i686-cygwin-threads-64int/auto/Win32CORE/Win32CORE.a seperately. (Sorry Yaakov) -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: clisp crashes on startup
On Fri, Jul 13, 2012 at 9:26 AM, Corinna Vinschen wrote: > On Jul 13 07:52, Reini Urban wrote: >> On Fri, Jul 13, 2012 at 2:40 AM, Corinna Vinschen wrote: >> > On Jul 12 20:48, Daniel Colascione wrote: >> >> On 7/10/12 8:41 AM, Daniel Colascione wrote: >> >> > On 7/10/12 1:13 AM, Corinna Vinschen wrote: >> >> >> On Jul 9 21:59, Daniel Colascione wrote: >> >> >>> On 7/9/12 2:26 PM, Daniel Colascione wrote: >> >> >>>> [snip] >> >> >>> >> >> >>> It turns out that clisp crashes only when I've rebased DLLs into the >> >> >>> high portion of the 4GB WOW64 address space. >> >> >> >> >> >> Where did you rebase them to? You know that on WOW64 and with the >> >> >> bigaddr flag on, the application heap is located at 0x8000 by >> >> >> default, right? Perhaps some of your DLLs just collide with that? >> >> > >> >> > I'm using a starting base address of 0xC800; I haven't had >> >> > problems with any other program. >> >> >> >> It turns out that clisp uses bit 31 of each pointer for its gc mark >> >> bit. No wonder the thing blows in bigaddr-aware mode. clisp _does_ >> > >> > Ouch. >> > >> >> work, however, when compiled with -DWIDE. In this mode, clisp uses two >> >> words for each lisp value --- one for the pointer and one for the >> >> metadata. >> >> Hmm, I do not really want to maintain lisp32.exe and lisp64.exe >> variants, but maybe >> upstream can be persuaded to make that distinction in the clisp.exe driver. >> It's only for huge data and bad rebase addresses. >> And for huge data a self-compiled clisp makes sense to me. >> Serious lisp users use better lisp compilers anyway which compile >> to native code. (sbcl, lispworks, allegro). >> clisp's main strength is fast startup and fast IO. >> >> >> Also, clisp has a LINUX_NOEXEC_HEAPCODES mode that also >> >> works, and without bloating memory use, but that requires that no real >> >> virtual address be in the range [0xC000, 0xDFFF]. >> > >> > That can't be guaranteed. WOW64 provides the full 32 bit VM address >> > space. >> >> Maybe also a documentation issue for rebaseing. > > That has nothing to do with rebasing. If you build clisp with a recent > gcc, it will have the "bigaddr" flag set in the file header since > Cygwin's gcc sets that by default. While DLLs should be rebased from > 0x7000 downwards as usual, the applications heap, as well as > thread stacks, as well as shared memory regions created with mmap(2) > or shmat(2) will be in the high memory area starting at 0x8000. > > THe bottom line is, if the distro clisp isn't 32 bit clean, which it > apparently isn't using default settings, it should either be rebuilt > with -DWIDE, or it should have the bigaddr flag removed from the > file header by default (peflags -l0). Thanks. This deserves an update now. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: clisp crashes on startup
On Fri, Jul 13, 2012 at 2:40 AM, Corinna Vinschen wrote: > On Jul 12 20:48, Daniel Colascione wrote: >> On 7/10/12 8:41 AM, Daniel Colascione wrote: >> > On 7/10/12 1:13 AM, Corinna Vinschen wrote: >> >> On Jul 9 21:59, Daniel Colascione wrote: >> >>> On 7/9/12 2:26 PM, Daniel Colascione wrote: >> >>>> [snip] >> >>> >> >>> It turns out that clisp crashes only when I've rebased DLLs into the >> >>> high portion of the 4GB WOW64 address space. >> >> >> >> Where did you rebase them to? You know that on WOW64 and with the >> >> bigaddr flag on, the application heap is located at 0x8000 by >> >> default, right? Perhaps some of your DLLs just collide with that? >> > >> > I'm using a starting base address of 0xC800; I haven't had >> > problems with any other program. >> >> It turns out that clisp uses bit 31 of each pointer for its gc mark >> bit. No wonder the thing blows in bigaddr-aware mode. clisp _does_ > > Ouch. > >> work, however, when compiled with -DWIDE. In this mode, clisp uses two >> words for each lisp value --- one for the pointer and one for the >> metadata. Hmm, I do not really want to maintain lisp32.exe and lisp64.exe variants, but maybe upstream can be persuaded to make that distinction in the clisp.exe driver. It's only for huge data and bad rebase addresses. And for huge data a self-compiled clisp makes sense to me. Serious lisp users use better lisp compilers anyway which compile to native code. (sbcl, lispworks, allegro). clisp's main strength is fast startup and fast IO. >> Also, clisp has a LINUX_NOEXEC_HEAPCODES mode that also >> works, and without bloating memory use, but that requires that no real >> virtual address be in the range [0xC000, 0xDFFF]. > > That can't be guaranteed. WOW64 provides the full 32 bit VM address > space. Maybe also a documentation issue for rebaseing. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl switch question /setup.exe
On Thu, Jul 12, 2012 at 11:13 AM, DEWI - N. Zacharias wrote: > As far as I understand the discussion it is necessary to reinstall all > modules which are not part of the cygwin packages. Not all old modules, just the old site_perl/i686-cygwin XS modules. The others can happily co-exist. You can also install both perl versions in parallel. The only conflict is /usr/bin/perl.exe and some scripts in /usr/bin/ Simply install one and then manually extract the other favored perl, like tar xfj ...down/http/release/perl/perl-5.10.1-5.tar.bz2 -C / > Because this will consume a lot of time (rebase manually after every step > etc. ) I want to keep the old Version of perl for some time. A full reinstall of my ~1000 cpan modules required 2x perlrebase. Not that much hurt as with 5.10. > Is there a way to prevent setup.exe installs the new version permanently . Hack your /etc/setup/installed.db and fake the latest perl version. Be sure to have a backup patch. grep perl.*5.10.1 /etc/setup/installed.db -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl-5.14.2 switch
On Thu, Jul 12, 2012 at 11:14 AM, Corinna Vinschen wrote: > On Jul 12 10:24, Reini Urban wrote: >> Well, I'm not so happy with threads. They seem to be more broken than with >> 5.10. >> But I like 5.14.2 generally at most of all also, much better than the >> completely flawed 5.16. > > Is this thread problem something Cygwin-specific, a Cygwin bug perhaps? > If so, can you nail that down into a simple C testcase? The failing thread tests in perls testsuite are unfortunately not so simple. Mostly torture tests. google's threadsanitizer might come handy. I found a lot of perl bugs with the related addresssanitizer. I'm pretty sure it's perls fault here, because mingw has the same problems. And the were some subtle changes between 5.10 and 5.14. I tried to improve it with a patch, but it didn't help much. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Is Emacs 24.1 on its way?
On Thu, Jul 12, 2012 at 7:13 AM, Nikolai Weibull wrote: > On Thu, Jul 12, 2012 at 2:04 PM, Ken Brown wrote: >> On 7/12/2012 7:42 AM, Nikolai Weibull wrote: > >>> Is Emacs 24.1 on its way? 24.0.96-2 seems to be the latest release >>> available. 24.1 has been out for quite some time now. > >> I have it all ready to go, but I'm waiting for cygwin-1.7.16 before I >> release it, because of the problem reported here: >> >> http://cygwin.com/ml/cygwin/2012-05/msg00424.html This is an X issue but... When you announce it, maybe you could add that X forwarding is disabled by default in sshd. You have to manually enable it in /etc/sshd_config to be able start your cygwin emacs from remote. I *live* in remote emacs sessions, much better than tramp. --- /etc/sshd_config~ 2012-07-12 09:21:01.0 -0500 +++ /etc/sshd_config2012-07-12 09:21:48.359375000 -0500 @@ -90,7 +90,7 @@ #AllowAgentForwarding yes #AllowTcpForwarding yes #GatewayPorts no -#X11Forwarding no +X11Forwarding yes #X11DisplayOffset 10 #X11UseLocalhost yes #PrintMotd yes -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl-5.14.2 switch
On Thu, Jul 12, 2012 at 12:19 AM, Achim Gratz wrote: > Steven Hartland writes: >> Unfortunately the current perl_vendor install is so broken cpan >> won't allow you to fix it with simple "install" unless you know >> the exact missing modules and just breaks in some very strange >> and random ways. Like missing protocol for ftp in LWP You are right. Back when I managed the _vendor list LWP was still pre-6.0 and had different deps. I needed LWP to get CPAN and then CPAN::TestReporter to work (at least bootstrap), so people can manage their own packages, and do not rely on cygwin packages. And the upstream maintainers get windows reports about failures, which they need to fix their stuff. They always complain not getting any windows reports, so they rather bitch. At least they get cygwin reports for some time now. I've updated the list of missing deps yesterday. > I suggested to use cpanminus — not cpan — for a reason. It is possible > to get things to eventually work as you want via CPAN, but it is much > less effort to do so via cpanminus. You can then continue using CPAN > for new modules if you wish. Agreed. > Remove perl_vendor first, in the end this is much easier than papering over it > via site-perl. Sorry for the missing deps conflicts. This will be fixed in 5.14.2-3. > Also, make sure you have removed all remnants from perl-5.10 (including > locally installed modules). The ability of 5.14 to fall back to modules > that were installed for 5.10 is a double-edged sword, the two versions > are sufficiently different so that I would not want to mix them at the > module level. I do not agree. XS modules are not looked up from 5.10, and there is no problem to continue using old modules if they were never updated on CPAN. If so, you well get new ones anyway with your next cpan or cpanm update. It's a one-liner, but needs a lot of time to re-install everything from scratch. $ cat ~/bin/cpanautoinstall #!/usr/bin/env perl use CPAN; CPAN::Shell->install(CPAN::Shell->r) or just: $ perl -MCPAN -e'CPAN::Shell->install(CPAN::Shell->r)' One other remaining problem is libtool's inability to mix static Win32CORE.a with shared, so I'll probably add Win32CORE.o to libperl instead. It's a shame. But perl is also blame as it still does not support installing static_ext .a libs. I have to do that manually. > Last but not least, Reini has asked for testers of the new perl quite a > while back and didn't get all that many responses. Even with those > kinks in perl_vendor (which I'm sure he'll fix) the 5.14 to me is the > least problematic perl version on Cygwin so far. I have only a glimpse > of how much work that must have been and I really appreciate it. I'm > sure Reini wouldn't mind if someone just took the sources for > perl_vendor and fixed whatever needs fixing and feed back the changes to > him... Well, I'm not so happy with threads. They seem to be more broken than with 5.10. But I like 5.14.2 generally at most of all also, much better than the completely flawed 5.16. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl-5.14.2 switch
On Wed, Jul 11, 2012 at 4:53 AM, Yaakov (Cygwin/X) wrote:
> On Tue, Jul 10, 2012 at 1:01 PM, Reini Urban wrote:
>> I'll be switching perl from 5.10 to 5.14 in the next days.
>
> Another issue:
>
> $Config{static_ext} is defined as Win32CORE. The problem is that any
> use of ExtUtils::Embed then requires Win32CORE; its bootstrap call is
> included by xsinit and the static library added to ldopts, resulting
> in the w32_* functions being exported by any EU::E module.
Yes, same as for the Cygwin:: functions.
> Where this really breaks things is where a EU::E module is linked with
> libtool (as in gnumeric's perl-loader plugin): the xsinit-generated
> code calls boot_Win32CORE() but libtool will drop any static link
> libraries when creating a shared library/module, meaning the link
> fails with an unresolved reference to said function.
>
> AFAICS, static_ext should be empty; packages which actually need the
> w32_* symbols can add Win32CORE as an argument to the EU::E functions.
I see the problem, but I'm afraid that I cannot move Win32CORE from
static to dynamic now.
Generally we must have the ability to support both types of exts,
static and dynamic. Some internal exts are also static, such as
Cygwin, Internals, utf8, UNIVERSAL, DynaLoader, PerlIO, mro and
partially version, attributes, Tie::Hash::NamedCapture. But they are
included in libperl.
Previously I solved this by adding Win32CORE.o to libperl itself.
Should I do that?
--
Reini Urban
http://cpanel.net/ http://www.perl-compiler.org/
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl-5.14.2 switch
On Tue, Jul 10, 2012 at 9:19 PM, Yaakov (Cygwin/X) wrote:
> On Tue, Jul 10, 2012 at 6:51 PM, Reini Urban wrote:
>> On Tue, Jul 10, 2012 at 6:10 PM, Yaakov (Cygwin/X) wrote:
>>> Found another problem which breaks gtk2-perl modules (which link
>>> against each other). The following change needs to be made in
>>> ExtUtils::Liblist::Kid::_unix_os2_ext(), line 135:
>>>
>>> - && -f ($fullname="$thispth/lib$thislib.$Config_dlext")) {
>>> + && -f ($fullname="$thispth/$thislib.$Config_dlext")) {
>>>
>>> I have made this change locally and am continuing the rebuild for Ports.
>>
>> I do not really understand. A few lines below we check for this case
>> elsif ( -f ( $fullname = "$thispth/$thislib.dll" ) ) {
>> }
>> and skip then.
>
> I don't see that line in my file. Perhaps this is a newer version or
> local modification on your part?
Not that I know of.
Can you please check the perl-5.14.2-2 test version I just uploaded?
--
Reini Urban
http://cpanel.net/ http://www.perl-compiler.org/
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl-5.14.2 switch
On Tue, Jul 10, 2012 at 6:10 PM, Yaakov (Cygwin/X) wrote:
> On Tue, Jul 10, 2012 at 5:36 PM, Reini Urban wrote:
>> On Tue, Jul 10, 2012 at 3:56 PM, Yaakov (Cygwin/X) wrote:
>>> Your rebase pure_install changes in EU::MM_Cygwin do not take DESTDIR
>>> into account, breaking cygport. Line 195 of said module needs to be
>>> changed to (as one long line):
>>>[snip]
>>
>> Great find!
>>
>> I've completed my remaining deps also, so only Volker is missing with one.
>
> I doubt perl-ming is used by many, so if Volker is busy, let's not wait for
> it.
>
>> I'll fix this and do the switch ASAP.
>> Thanks.
>
> Found another problem which breaks gtk2-perl modules (which link
> against each other). The following change needs to be made in
> ExtUtils::Liblist::Kid::_unix_os2_ext(), line 135:
>
> - && -f ($fullname="$thispth/lib$thislib.$Config_dlext")) {
> + && -f ($fullname="$thispth/$thislib.$Config_dlext")) {
>
> I have made this change locally and am continuing the rebuild for Ports.
I do not really understand. A few lines below we check for this case
elsif ( -f ( $fullname = "$thispth/$thislib.dll" ) ) {
}
and skip then.
Is there a corner-case case where you have a lib.dll and no .dll,
and lib.dll should not be linked against?
I've also found one more, so I will switch tomorrow. It needs more tests.
--- ./usr/lib/perl5/5.14/ExtUtils/MM_Cygwin.pm~ 2012-07-10
18:24:11.977053200 -0500
+++ ./usr/lib/perl5/5.14/ExtUtils/MM_Cygwin.pm 2012-07-10
18:29:50.461428200 -0500
@@ -189,8 +189,8 @@
my ($rebasever) = $rebaseverstr =~ /rebase version ([0-9.]+)/;
$rebasever =~ s/(\d\.\d+)\./$1/;
if ($rebasever > 3.01) { # new rebase 3.0.2 with database
my $INSTALLDIRS = $self->{INSTALLDIRS};
- my $INSTALLLIB = $self->{"INSTALL".uc($INSTALLDIRS)."ARCH"};
+ my $INSTALLLIB = $self->{"INSTALL". ($INSTALLDIRS eq 'perl' ?
'ARCHLIB' : uc($INSTALLDIRS)."ARCH")};
my $dll =
"$INSTALLLIB/auto/$self->{FULLEXT}/$self->{BASEEXT}.$self->{DLEXT}";
$s =~ s|^(pure_install ::
pure_\$\(INSTALLDIRS\)_install\n\t)\$\(NOECHO\)
\$\(NOOP\)\n|$1\$(CHMOD) \$(PERM_RWX) \$(DESTDIR)$dll\n\t/bin/rebase
-s \$(DESTDIR)$dll\n|m;
}
--
Reini Urban
http://cpanel.net/ http://www.perl-compiler.org/
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perl-5.14.2 switch
On Tue, Jul 10, 2012 at 3:56 PM, Yaakov (Cygwin/X) wrote: > On Tue, Jul 10, 2012 at 1:01 PM, Reini Urban wrote: >> I'll be switching perl from 5.10 to 5.14 in the next days. > > Your rebase pure_install changes in EU::MM_Cygwin do not take DESTDIR > into account, breaking cygport. Line 195 of said module needs to be > changed to (as one long line): > > $s =~ s|^(pure_install :: > pure_\$\(INSTALLDIRS\)_install\n\t)\$\(NOECHO\) > \$\(NOOP\)\n|$1\$(CHMOD) \$(PERM_RWX) \$(DESTDIR)$dll\n\ttest -n > "\$(DESTDIR)\" \|\| /bin/rebase -s $dll\n|m; > > I have fixed my local copy in the meantime and am continuing to work > on the upgrade, but this is a blocker for 5.14. Great find! I've completed my remaining deps also, so only Volker is missing with one. I'll fix this and do the switch ASAP. Thanks. Then we can improve rebasing with Achim's patch. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
perl-5.14.2 switch
I'll be switching perl from 5.10 to 5.14 in the next days. These are the packages which need to be switched also: perl-net-libproxy Yaakov S perl-locale-gettext Yaakov S perl-dbd-mysql Yaakov S perl-dbiYaakov S perl-tk Yaakov S perl-win32-gui Reini Urban (ready as test) perl-libwin32 Reini Urban subversion-perl David Rothenberger (ready as test) perl-ming Volker Zell perl-image-magick Marco Atzeri (ready as test) perl-graphics-magickMarco Atzeri (ready as test) I'll change the setup.hints from the one marked as ready as test by myself, no action from your side needed. Just adjust your private hints also please. I just need Yaakov and Volker to followup with rebuilt packages. Can you please confirm? You can do it earlier with the perl test package or later. If later, you need to update perl and rebuild your packages. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: mathomatic-16.0.0.-1
New major release. See http://mathomatic.orgserve.de/changes.txt Cygwin build changes: * added _CYGPORT_RESTRICT_debuginfo_ * added rlwrap dependency for rmath * added missing libncursesw10 dependency * adapted src.patch a bit * matho m4 needs -i, m4 -e is deprecated * added optional m4/degrees.m4. add this to your m4/functions.m4 for trig functions that use degree units instead of radians * new /usr/bin/matho, /usr/bin/rmath binaries * new m4 run-time dependency * new htmlcard About: Mathomatic is a highly portable, general purpose symbolic math program that can solve, simplify, combine, differentiate, integrate, and compare algebraic equations. It can do standard, complex number, and polynomial arithmetic. It is extremely easy to use and has pretty colored, easily readable display of equations. See http://www.mathomatic.org/ -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: clisp crashes on startup
On Sat, Jul 7, 2012 at 2:07 PM, Daniel Colascione wrote: > On 7/7/2012 10:44 AM, marco atzeri wrote: >> On 7/7/2012 6:19 PM, Reini Urban wrote: >>> On Sat, Jul 7, 2012 at 8:41 AM, Daniel Colascione wrote: >>>> On 7/7/12 6:04 AM, marco atzeri wrote: >>>>> On 7/7/2012 12:45 AM, Daniel Colascione wrote: >>>>>> $ clisp >>> >>> Looks like a missing dependency or wrong dll perm. I saw none in your >>> cygcheck. >>> >>> Can you try >>> $ ldd /usr/lib/clisp-2.48/base/lisp.exe >>> and see of one dll is missing. >>> And check if one of the dll's has no x perm set. >> >> >> $ cygcheck /usr/lib/clisp-2.48/base/lisp.exe >> >> should be better. ldd does not advise about missing dll's > > $ cygcheck /usr/lib/clisp-2.48/base/lisp.exe > C:\lib\clisp-2.48\base\lisp.exe > C:\bin\cyggcc_s-1.dll > C:\bin\cygwin1.dll > C:\Windows\system32\KERNEL32.dll > C:\Windows\system32\API-MS-Win-Core-RtlSupport-L1-1-0.dll > C:\Windows\system32\ntdll.dll > C:\Windows\system32\KERNELBASE.dll > C:\Windows\system32\API-MS-Win-Core-ProcessThreads-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-Heap-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-Memory-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-Handle-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-Synch-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-File-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-IO-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-ThreadPool-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-LibraryLoader-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-NamedPipe-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-Misc-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-SysInfo-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-Localization-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-ProcessEnvironment-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-String-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-Debug-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-ErrorHandling-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-Fibers-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-Util-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-Profile-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Security-Base-L1-1-0.dll > C:\bin\cygcrypt-0.dll > C:\bin\cygiconv-2.dll > C:\bin\cygintl-8.dll > C:\bin\cygncurses-9.dll > C:\bin\cygreadline7.dll > C:\bin\cygncursesw-10.dll > C:\Windows\system32\USER32.dll > C:\Windows\system32\GDI32.dll > C:\Windows\system32\API-MS-Win-Core-LocalRegistry-L1-1-0.dll > C:\Windows\system32\LPK.dll > C:\Windows\system32\USP10.dll > C:\Windows\system32\msvcrt.dll > C:\Windows\system32\API-MS-Win-Core-Console-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-DateTime-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Core-Interlocked-L1-1-0.dll > C:\Windows\system32\ADVAPI32.dll > C:\Windows\system32\API-MS-WIN-Service-Core-L1-1-0.dll > C:\Windows\system32\API-MS-WIN-Service-winsvc-L1-1-0.dll > C:\Windows\system32\API-MS-WIN-Service-Management-L1-1-0.dll > C:\Windows\system32\API-MS-WIN-Service-Management-L2-1-0.dll > C:\Windows\system32\RPCRT4.dll > C:\Windows\system32\SspiCli.dll > C:\Windows\system32\CRYPTBASE.dll > C:\Windows\system32\API-MS-Win-Core-DelayLoad-L1-1-0.dll > C:\Windows\system32\API-MS-Win-Security-LSALookup-L1-1-0.dll > C:\bin\cygsigsegv-2.dll > C:\Windows\system32\OLE32.dll > C:\Windows\system32\OLEAUT32.DLL > > ldd doesn't report an error either. ldd's output _is_ a bit odd, however: > > $ ldd /usr/lib/clisp-2.48/full/lisp.exe > ntdll.dll => /Windows/SysWOW64/ntdll.dll (0x7de7) > kernel32.dll => /Windows/syswow64/kernel32.dll (0x7dd6) > KERNELBASE.dll => /Windows/syswow64/KERNELBASE.dll (0x7d85) > cyggcc_s-1.dll => /usr/bin/cyggcc_s-1.dll (0xc5ab) > cygwin1.dll => /usr/bin/cygwin1.dll (0x6100) > cygcrypt-0.dll => /usr/bin/cygcrypt-0.dll (0xc640) > cygdb-4.5.dll => /usr/bin/cygdb-4.5.dll (0xc5fd) > cygfcgi-0.dll => /usr/bin/cygfcgi-0.dll (0xc5e9) > cyggdbm-4.dll => /usr/bin/cyggdbm-4.dll (0xc59e) > cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0xc411) > cygintl-8.dll => /usr/bin/cygintl-8.d
Re: clisp crashes on startup
On Sat, Jul 7, 2012 at 8:41 AM, Daniel Colascione wrote: > On 7/7/12 6:04 AM, marco atzeri wrote: >> On 7/7/2012 12:45 AM, Daniel Colascione wrote: >>> $ clisp Looks like a missing dependency or wrong dll perm. I saw none in your cygcheck. Can you try $ ldd /usr/lib/clisp-2.48/base/lisp.exe and see of one dll is missing. And check if one of the dll's has no x perm set. clisp.exe is just a driver, which exec's base/lisp.exe or full/lisp.exe -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Built perl 5.6.2 on Cygwin 1.7.11, but get SIGABRT from resulting perl.exe
On Thu, Jun 21, 2012 at 12:46 PM, Nicholas DiPiazza wrote: > I'm getting a SIGABRT when running a perl 5.6.2 that i built on cygwin > 1.7.11. > > See ldd from a working perl 5.10 http://pastebin.com/ytjVYg4F versus my > broken perl 5.6.2 http://pastebin.com/YXZ29NG6. > > I turned on -DDEBUGGING on the ./Configure script. Here is the gdb backtrace > I have: > > http://paste.scsys.co.uk/201064 > > Are there libraries missing? What's going on here? Looks like a failing rebase on an incredibly low address 0xa7. Try rebaseall. And then maybe a $ perlrebase 5.6.2 But it rather looks like a system dll. libz.dll maybe. Note: The argument 5.6.2 to find your right executable suffix >From my experience only lib/File/Find.pm from a newer perl is required (I took 5.8.1), otherwise you not be able to installe other modules because the are not found. I usually install old stuff with App::perlall and/or Devel::PatchPerl -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: parrot-4.3.0-1, rakudo and rakudo-star-201204-1 (perl6)
I updated the Cygwin distributions of parrot-4.3.0-1, rakudo-201204.1-1 (aka perl6) and rakudo-star-201204-1 These are stable, a so-called "supported" releases. Canonical homepages: http://www.parrot.org/ http://www.rakudo.org/ Canonical downloads: http://www.parrot.org/release/current http://github.com/rakudo/rakudo/downloads http://github.com/rakudo/star/downloads Packaging Details: * blizkost (perl5 in perl6) is gone. * winxed and nqp is new, parrot-nqp is an old version unfortunately required to bootstrap. maybe we'll add a new nqp package somewhen. * you need at least 2GB free RAM and an initialized rebase database to rebuild New in parrot See http://parrot.org/news/2012/Parrot-4.3.0 - Core + Winxed snapshot updated to 1.7.0 + Add type introspection to lexical variables. + New 'tools/release/parrot_github_release.pl' script to automate updates to the 'parrot.github.com' and 'parrot-docsx' repositories. + Numerous casting and consting fixes thanks to GCC 4.8 . - Documentation + Updated 'docs/projects/release_manager_guide.pod' + Updated 'docs/projects/release_parrot_github_guide.pod' + Improved function documentation. - Tests - Community - Platforms + Fixed alignment issues on ia64, sparc and mipsel. + Fixed a platform-specific issue with dlclose(). rakudo release announcement: http://rakudo.org/2012/04/26/announce-rakudo-star-2012-04-a-useful-usable-early-adopter-distribution-of-perl-6/ * much improved startup time * much more robust module precompilation * autovivification for arrays and hashes is implemented again * many phasers like PRE, POST and REDO are now implemented * improved support for calling C functions and modelling structs and arrays via NativeCall.pm6 * now includes modules URI, LWP::Simple, jsonrpc and Bailador (a Perl 6 port of Dancer) This release also contains a range of bug fixes, improvements to error reporting and better failure modes. Many more exceptions are thrown as typed exceptions. notable incompatible changes from the previous releases: * the ‘lib’ directory is not included in the default module search path anymore. You can manipulate the search path with the PERL6LIB environment variable -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Test update: perl-5.14.2-1, please update your dependent packages
On Thu, May 3, 2012 at 9:24 AM, Achim Gratz wrote: > Reini Urban x-ray.at> writes: >> perl has been updated to 5.14.2-1 as test in the Experimental section. >> >> It looks pretty stable to me when I tested it in the last 2 weeks. > > I've hit two interesting snags (perl_vendor is installed): > > 1) Some modules, when built with cpanminus fail at test, but the same module > built with cpan tests OK (File::Slurp being the most simple example I have > right > now). Interesting. I'll look into that. I regularly try out cpanm also. I thought we only got problems with Module::Install and Module::Build cs. EUMM. > 2) If I install another module that uses LWP (HTTP::Status, for example), > then I > also need to reinstall LWP. Otherwise I'm getting errors like these: > > Attempt to reload LWP/Protocol/http.pm aborted. > Compilation failed in require at (eval 7) line 2. I could not repro this. I built HTTP::Status just fine. I'll think about it. > Lastly, I'd much prefer if the vendor modules would be separate entities to > install, this would make it easier to keep proper dependencies among them. I > will re-build all these modules plus some 150 more with cygport anyway > (provided > I don't hit a roadblock), so once that works I could send you the > perl-*.cygport > files. Sorry, too much manual work. I rather prefer only one single dependency and update step than 150. These are just the basics to get CPAN and CPAN::Reporter working, the rest you can do by your own. You''l only need such cygports deps (like Yaakov needs them) if you build projects requiring perl modules. There are not many. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
libffi-devel resp., extra libffi packages?
For the upcoming rakudo + parrot releases I'd like to have ffi.h and maybe a libff.dll.a import library. Maybe it's better to provide an extra libffi package because our gcc is so much far behind. We are currently at API rev. libffi6, version 3.0.11. Anyone interested? I'll do it temp. by adding the ffi.h header for our cygffi-4.dll to the parrot build in my src patch, needed only for building. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: gdb hanging in emacs
On Sun, Apr 29, 2012 at 7:53 AM, Ken Brown wrote: > The only other thing I can suggest is that you try emacs-24, assuming you're > currently using emacs-23. emacs-24 uses a different method of invoking gdb > (based on GDB/MI) than emacs-23, so it might conceivably work better. If > you want to try this, I can tell you off list how to get my build of the > most recent pretest for emacs-24.1. Ken, How about a test version of a 24 snapshot? I prefer it by far over 23 stable for a few months now, and it seems to be more stable to me than 23. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Test update: perl-5.14.2-1, please update your dependent packages
perl has been updated to 5.14.2-1 as test in the Experimental section.
It looks pretty stable to me when I tested it in the last 2 weeks.
This is to build the 102 (!) dependent packages. I hope the
dependencies can be done
in the next month. Please upload them as test. I'll make the big
switch then by myself
when most packages are updated.
I added a new subpackage perl_vendor which includes all formerly
shipped vendor_perl modules,
which are mainly required to build and test and report test results of
other CPAN modules.
I also added a new subpackage perl_debuginfo which includes stripped
debug symbols
as in fedora. They might come handy if you want to debug into perl or
perl XS modules.
The archname and some minor internals changed. mymalloc is gone.
threads are still unstable. cc is gcc-4.
There is a new Cygwin::sync_winenv function.
The old 5.10 and 5.8 non-arch module paths are kept in @INC, so there
is less need to update.
rebase errors still happen, but are much less common than with 5.10.
There's special code in the ExtUtils::MakeMaker installer to re-use previous
image base addresses on cpan updated dll's.
With a full cpan re-install I got 2 rebase problems. Try to close
bigger dll hogs such the
MS Internet Explorer or SQL Server when doing cpan updates.
I've got some problems with perl-Win32-GUI, but I've got more problems
with perl 5.16 (to be)
than with 5.14, so 5.14 it will be for the time being, at least until
5.16.1 will come out.
5.16.0 looked better in theory than in practise.
In theory I could support parallel perl packages, perl510 and perl514
(or perl516),
but I doubt that other packagers want to support double packages and
rename all their names.
The clashes can be solved via alternatives. manpages and scripts only
for the latest.
Update recommendations from 5.10:
Since 5.14 is not installed in parallel to 5.10 (it is possible, but not
with this package), all your old 5.10 binary modules will need to be
reinstalled for 5.14.
BEFORE INSTALLATION of this 5.14
# get the list of installed 5.8 modules
$ perl -MExtUtils::Installed \
-e'print join("\n", new ExtUtils::Installed->modules)' > module.list
AFTER INSTALLATION of this 5.14
# install all previous modules for 5.10
$ cpan `cat module.list`
--
Reini Urban
http://cpanel.net/ http://www.perl-compiler.org/
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated clamav-0.97.4-1
I've updated clamav to the latest stable release 0.97.4 ClamAV 0.97.4 includes minor bugfixes, detection improvements and initial support for on-access scanning under Mac OS X (see contrib/ClamAuth). This update is recommended for all users. Project description: Clam AntiVirus is an anti-virus toolkit. It provides a number of utilities, including a flexible and scalable multi-threaded daemon, a commandline scanner, and a tool for automatic database updates. The core of the package is an anti-virus engine available as a shared library. 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. Once you've downloaded setup.exe, run it and select "Editors" or "Text" and then click on the appropriate fields until the above announced version numbers appear if they are not displayed already. If your mirror doesn't yet have the latest version of this package after 24 hours, you can either continue to wait for that site to be updated or you can try to find another mirror. Please send questions or comments to the Cygwin mailing list at: cygwin at cygwin.com If you want to subscribe go to: http://cygwin.com/ml/cygwin/ I would appreciate if you would use this mailing list rather than emailing me directly. This includes ideas and comments about the setup utility or Cygwin in general. If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: need help with perl script and rsync
On Tue, Feb 14, 2012 at 3:28 PM, wrote: > We use ActiveState perl in a backup processes at my work. A programmer > created a perl script to create an incremental backup using rsync. The > script does not do the incremental backup, just a full backup. It worked in > winxp, but now that we are using it on win7 its not incrementing. > > I cannot get in contact with the programmer. Is there someone here that can > look at the script and find out what the issue is? You can send it to the list or to me. rsync is cygwin, activestate perl is not, so you have to use path conversions, which are unnatural to both. Easiest would be to use cygwin perl and get accustomed to POSIX paths and permissions. PS: rsync does incremental backups natively. I don't see the apparent need for a perl driver. But even PAUSE uses a perl driver to rsync for performance reasons with huge mirroring costs. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [Packaging bug] perl-5.10.1-5: Superfluous symlink for cygperl5_10.dll
On Fri, Feb 17, 2012 at 10:17 AM, Dr. Volker Zell wrote: > In the latest perl-5.10.1-5 there is a symlink > /usr/lib/perl5/5.10/i686-cygwin/CORE/cygperl5_10.dll > for > /usr/bin/cygperl5_10.dll > > which breaks 'make check' when trying to run the testsuite for > openldap when it's perl enabled. This trick is needed to enable -Dlibperl=cygperl5_10.dll for building XS extensions without going through the importlib. This way the dll can be named as you wish, to enable multiple versions and features (threaded/non-threaded, debug) of perl together. > The libtool generated wrapper for slapd includes the following > PATH statement: PATH=:/usr/local/lib:/usr/local/bin:/usr/lib/perl5/5.10/i686-cygwin/CORE:/misc/src/release/openldap-2.4.29-1/build/libraries/libldap_r/.libs:/misc/src/release/openldap-2.4.29-1/build/libraries/liblber/.libs:$PATH > So when the real slapd starts up it exits with exit code 127 because > it finds the symlink for cygperl5_10.dll before the real one. I see. /usr/lib/perl5/5.10/i686-cygwin/CORE is wrong in PATH. It only belongs to LIBPATH. There are no binaries there to pickup. > Shouldn't that symlink be there in the first place ? > For now I removed it and the openldap test suite > works again. No, please remove /usr/lib/perl5/5.10/i686-cygwin/CORE from your path in your Makefile. The symlink is needed to build perl extensions. windows needs the dll to be in the path which is /usr/bin. ld needs to link against the dll and expects it in /usr/lib/perl5/5.10/i686-cygwin/CORE, hence the symlink, because ld understands the symlink, windows not. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: add -debuginfo packages
On Sat, Feb 18, 2012 at 11:58 AM, Christopher Faylor wrote:
> On Sat, Feb 18, 2012 at 04:47:48PM +, Jon TURNEY wrote:
>>On 21/08/2009 00:40, Yaakov (Cygwin/X) wrote:
>>> On 04/08/2009 13:58, Reini Urban wrote:
>>>> Rather than stripping our exe's and dll's I suggest to strip the debug
>>>> info into
>>>> seperate /usr/lib/debug/path/file.dbg and package them seperately in
>>>> -debuginfo
>>>> packages such as with fedora.
>>
>>FWIW, attached is the patch I've been using to do this, based on Reini's
>>patch, updated to address some of your concerns.
>>
>>This can, as you suggested, strip the symbols to a location outside of ${D}
>>and create a single debuginfo package containing those symbols for each
>>cygport.
>>
>>I know that support for these packages in upset and setup has been rejected by
>>cgf, but it's still useful to me to keep the debuginfo for the packaged builds
>>of Xwin around.
>
> I can see why it would be useful but why do we need to change anything?
> Why can't you just release a xorg-server-debuginfo package and have
> people install that when you want them to collect debugging?
Fully agree.
There are only some use cases for this, and those who think it's good
can already do that, based on my three lines.
But it's two years and nobody so far did it, not even me yet, so it's
still premature to ask for upset or cygport support.
--
Reini
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Perl system() function works sometimes.
On Mon, Jan 30, 2012 at 7:47 PM, Gary E Barnes wrote:
> I'm confused about what you are talking about. In particular the "perl
> within perl" part. I have a perl script. It puts together shell commands
> and tries to run them using the system() call. There is no perl calling
> perl so far as I know.
Right. Sorry, I mixed that up.
system("scp machine:remote.file local.file"); calls
/bin/sh -c scp machine:remote.file local.file
system(qw(scp machine:remote.file local.file));
skips the /bin/sh part and executes scp directly.
> The script has worked fine for about two years on three machines. Now
> suddenly it doesn't work on any of them. I'm hoping that someone has an
> idea. It may not have anything whatsoever to do with perl as such. That
> is just where I am seeing the problem.
Because some DLL's use more memory and the perl DLL's have less room.
> "There is not enough DLL space." Interesting, I wasn't aware it was a
> limited resource as such (modulo those inherent in 32-bit addressing). Is
> there a way to determine what DLL space is in use at a given moment and
> what program(s) are using it? When I'm running this script the machine is
> a completely idle as I can make it. It is running only those things I
> have no way to turn off, like anti-virus. Could this problem be "just"
> that I need to find even more things to halt before running the script?
perlrebase tells you the last perl dll base, and rebaseall tells you
the cygwin base.
They should not overlap, and there should be room below perl, or you
might have to kill apps taking this space or perlrebase with a higher
base.
If you have no CPAN XS installations, rebaseall alone without
perlrebase is better.
BTW: With the new rebase package we keep a central database so there will be no
perl vs cygwin overlap. But I haven't finished the new perl package
yet which uses
that.
> My main questions are:
> 1) What could possibly have changed? I mean on the computer. I don't
> think all of our copies of Cygwin have changed recently. So some other
> DLL(s) changed perhaps? Got bigger?
1. The OS got bigger. Esp. Win7 compared to XP.
2. You might be running more programs.
3. New services running?
> 2) Is there some way to truly diagnose this problem? How would I go
> about it?
>
> I might be able to rearrange things so that I could call system with a
> list of strings most of the time. However simple things like this,
>
> system ("scp machine:remote.file local.file");
>
> have started failing where they've never failed before. My "perl -e"
> examples were just minimal-failing-programs that I discovered while trying
> to diagnose the problem. The script is no longer capable of getting to
> the more complicated stuff such as:
>
> system ("((tar czf - .. ; echo $? >/tmp/status) | ssh machine 'cat
> - > remote.file) ; exit `cat /tmp/status`'");
>
> I don't think things like that can be turned into a list of string
> arguments. I really do need to invoke a subshell (or do a great deal of
> process piping on my own).
Yes, that would be a lot of perl work to do that manually.
I prefer the shell to do that.
> Would it help reduce DLL space usage if I wrote the commands out to a file
> and ran the file as a shell script underneath Perl?
This is what system(string) does already.
But you can try to put more into a shell script, so perl has less work.
I always prefer shell scripts over perl scripts, but sometimes one has
to bite the bullet and switch over.
> On Mon, Jan 30, 2012 at 11:45 AM, Gary E Barnes wrote:
>> I have tried perlrebase and also rebaseall. I tried deleting cygwin
> from
>> the machine and reinstalling from scratch.
>> None of that fixes the problem. If it is some sort of rebase problem
> then
>> the usual tools don't fix it.
>>
>> And from what you said about calling execve when there are no
> interesting
>> shell redirections, it would appear
>> that perl calling system() simply doesn't work at all for some reason.
>
> Yes, it failed with a rebaseall-related fork failure because you used
> system
> with the system sh-wrapper. If you call it as list you wouldn't see this
> error.
>
> Yes, Calling perl within perl within perl will lead to memory conflicts.
> This a known problem we will have to live for a while unfortunately.
> There's not enough DLL space. Even less the more apps are loaded.
> Yes, this is fragile.
>
> That's why I recommended not to use system with strings.
--
Reini Urban
http://cpanel.net/ http://www.perl-compiler.org/
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Perl system() function works sometimes.
On Mon, Jan 30, 2012 at 11:45 AM, Gary E Barnes wrote: > I have tried perlrebase and also rebaseall. I tried deleting cygwin from > the machine and reinstalling from scratch. > None of that fixes the problem. If it is some sort of rebase problem then > the usual tools don't fix it. > > And from what you said about calling execve when there are no interesting > shell redirections, it would appear > that perl calling system() simply doesn't work at all for some reason. Yes, it failed with a rebaseall-related fork failure because you used system with the system sh-wrapper. If you call it as list you wouldn't see this error. Yes, Calling perl within perl within perl will lead to memory conflicts. This a known problem we will have to live for a while unfortunately. There's not enough DLL space. Even less the more apps are loaded. Yes, this is fragile. That's why I recommended not to use system with strings. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Perl system() function works sometimes.
On Fri, Jan 27, 2012 at 3:50 PM, Gary E. Barnes wrote:
> perl -e 'system ("/bin/ls -l /tmp");' # still works
> perl -e 'system ("/bin/ls -l /tmp > /tmp/xxx");' # no longer works
> perl -e 'system ("(/bin/ls -l /tmp>");' # no longer works
>
> Perl's system() function is just the Unix system() call. The string
> argument is a command line to execute. The same commands work in a shell
> script (/bin/sh, /bin/csh, and /bin/bash).
You miss the important distinction: system indirectly via sh or
directly without.
perldoc -f system
With a string argument without certain shell-redirections or with list
it calls execve directly.
"/bin/ls -l /tmp > /tmp/xxx" uses an intermediate sh call to execute,
and this fails with an
out of memory = rebase problem.
> This is a sudden change of behavior we are seeing on our machines. We have
> several XP machines, some with old Cygwin installations and some with brand
> new ones. So I would hazard a guess that it is not due to any change in
> Cygwin.
rebaseall
> Here is a log of what happens. The call never seems to terminate. I've
> waited up to 15 minutes. ^C does not work. ^Z fortunately does. The first
> message (couldn't allocate) comes out after perhaps 15 seconds. The second
> message (wait failed) takes minutes to appear.
>
> --
> xp-1: perl -e ' system ( "/bin/ls -l /tmp" ); '
> total 5
> -r-xr-x---+ 1 geb Users 2007-10-15 18:37 XWin.log
> -r-xr-x---+ 1 geb Users 0 2007-11-27 18:16 sh-thd-1196200453
> -rw-rw-r--+ 1 geb None 177 2012-01-27 12:50 xxx
> xp-2: perl -e ' system ( "/bin/ls -l /tmp > /tmp/xxx" ); '
> 22 [main] sh 5216 C:\cygwin\bin\sh.exe: *** fatal error - couldn't
> allocate heap, Win32 error 487, base 0x97, top 0x9B, reserve_size
> 258048, allocsize 262144, page_const 4096
> 33 [main] sh 4312 child_info::sync: wait failed, pid 5216, Win32 error 0
> 335 [main] sh 4312 fork: child -1 - died waiting for longjmp before
> initialization, retry 0, exit code 0x100, errno 11
> 22 [main] sh 4696 C:\cygwin\bin\sh.exe: *** fatal error - couldn't
> allocate heap, Win32 error 487, base 0x97, top 0x9B, reserve_size
> 258048, allocsize 262144, page_const 4096
> 311004651 [main] sh 4312 child_info::sync: wait failed, pid 4696, Win32 error > 0
> 311004816 [main] sh 4312 fork: child -1 - died waiting for longjmp before
> initialization, retry 0, exit code 0x100, errno 11
> 22 [main] sh 4700 C:\cygwin\bin\sh.exe: *** fatal error - couldn't
> allocate heap, Win32 error 487, base 0x97, top 0x9B, reserve_size
> 258048, allocsize 262144, page_const 4096
> ^Z
--
Reini Urban
http://cpanel.net/ http://www.perl-compiler.org/
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Perl dumping core on Win7 for script that works fine on WinXP
Am 13.01.2012 um 18:17 schrieb KARR, DAVID: > I've been using Cygwin 1.5.25 on my XP box for quite a while. I have a Perl > script that has been running perfectly well for a long time. > > I'm helping another user get set up so they can run this script. He's on > Win7. He installed the latest Cygwin and installed all the required Perl > modules. He had some luck running the script, but now we're at a point where > the script runs for a couple of seconds then dies with a core dump. He's > running the shell as an administrator. > > I'm attaching the cygcheck output and the perl stackdump. > > I've checked the FAQ, and I don't see anything that jumps out at me. > > What could be happening here? > The stacktrace tells me nothing. Looks like a perl core bug. Can you send me your script in private so that I can reproduce it? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: broke my perlbrewed perl with rebase
On Thu, Dec 29, 2011 at 4:22 PM, Rafael Kitover wrote: > I made a perl to test some stuff with perlbrew, a 5.12.0. > > I installed some CPAN modules into it, then I needed to rebase because > of mapping errors. > > I made a copy of perlrebase and modified it thusly: > > #!/bin/sh > > baseaddr=0x5700 > > perl=`which perl` > > dll=$(ldd $perl | $perl -anle 'print $F[2] if /cygperl/') > > echo $dll >> rebase.lst > /usr/bin/find ~/perl5 -name \*.dll >> rebase.lst > /usr/bin/cat rebase.lst | /usr/bin/xargs chmod ug+w > [ -e /usr/bin/peflags.exe ] && /usr/bin/peflags -t $perl > /usr/bin/rebase -v -b $baseaddr -T rebase.lst > [ -e /usr/bin/peflags.exe ] && /usr/bin/grep \.dll rebase.lst \ > | /usr/bin/peflags -d0 -T - >/dev/null > > perlbrew puts its stuff into ~/perl5/perlbrew > > I ran this script, and now my perlbrewed perl no longer works at all. It > exits immediately when I run it, not even perl -v works. > > This is what I see in gdb `which perl` after doing a run: > Starting program: > /c/Users/rkitover/perl5/perlbrew/perls/perl-5.12.0/bin/perl > [New Thread 8156.0x9ec] > [Inferior 1 (process 8156) exited with code 0305] > > The perlbrew command I used was: > perlbrew install -n -j 3 perl-5.12.0 -D DEBUGGING -D optimize="-ggdb3" > -D usethreads > > Did I do something wrong with rebase here? I don't see the error immediately. You have to check the rebase.lst and ldd perl.exe. But I strongly advise against using perlbrew on cygwin. There's something odd going on with PERL5LIB and could not find a solution. Either us my build.sh and build_common.sh scripts to compile your perls or use my new App-perlall from my github or CPAN. Using a customized build.sh is still a bit better. It is easy to generate custom perl exe and dll and archlib's to seperate various perl installations globally, which can be easily rebased and maintained. I have almost every combination of perl versions, threaded/non-threaded, DEBUG/non-debug on cygwin to test in /usr/local/bin/ -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: perlrebase, is there no better way?
On Wed, Dec 28, 2011 at 5:56 PM, Rafael Kitover wrote: > perlrebase is great, but it has some shortcomings. > > You often have to break out of a cpan install and run it then continue, > then break out again, etc. to install some modules. > > It doesn't automatically detect local::lib and perlbrew libs (perhaps I > can patch it for that.) Maybe support for a list of other dirs in > ~/.perlrebase would be good. > > What if ExtUtils::MakeMaker and Module::Build, in the code for the .dll > link stage, would automatically rebase the resulting .dll to some > address as set in /etc/perlrebase.conf? Sure. That's the plan for the upcoming 5.14.2 release. We have a global rebase database now so it's even fast. It just is not stable enough, and my win PC broke down. > Reini, what do you think? -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Confusion with ACLs and Perl's file tests...maybe bug???
Thanks for the nice testcase. I'll try to take it upstream. But I'm not too confident that p5p will fix it, e.g. they refused to fix File::Copy::cp, keeping the perms as with /bin/cp for several years. I could recently fix the cygwin write check if you had admin rights though. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [TESTING] Updated: subversion-1.7.0rc4-1
On Fri, Sep 30, 2011 at 2:07 PM, David Rothenberger wrote: > IMPORTANT: This release has a new working copy format. To use this > release, you must manually upgrade your working copy format, > rendering it unusable with previous major releases. > > Please see the release notes > http://subversion.apache.org/docs/release-notes/1.7.html > for more details about the changes in Subversion. In particular you must run `svn cleanup` in ALL your repos BEFORE upgrading cygwin. And the after the cygwin install you can do: `svn upgrade` "Subversion 1.7 cannot upgrade working copies that a 1.6 client would have refused to operate upon before an svn cleanup was run (with a 1.6 client). In other words, before upgrading to 1.7, a 1.6 client must be used to run svn cleanup on all working copies that require cleanup. We regret for this limitation, but we had to introduce it in order for 1.7 to ship timely and without overcomplicating the internals" But I love the new centralized SQLite db. -- Reini -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
