perl-5.10.0-4 -> perl-5.10.0-5 site_perl update needed
2008/7/9 Reini Urban:
> 2008/7/9 Reini Urban:
>> 2008/7/8 Reini Urban:
>>> 2008/7/8 Gary R. Van Sickle:
Hi Reini,
It looks like something changed between perl 5.10.0-4 and -5 which breaks
the DateTime module from CPAN (version 0.4302, latest). The attached
Simple
Test Case(tm) results in only the following errors:
Use of uninitialized value $id in pattern match (m//) at
/usr/lib/perl5/site_perl/5.10/DateTime/Locale.pm line 65.
>>>
>>> Bad side-effect with a third party module in site_perl.
>>> Strange that I didn't see this in my tests, because I tested over
>>> thousand CPAN modules with this release.
>>> Oh, I see, I reported that it failed on June 5.
>>>
>>> $ cpan DateTime
>>> requires DateTime::Locale
>>>
>>> DateTime::Locale cannot be installed because of this error,
>>> but since you upgraded perl we have to fix DateTime::Locale now.
>>>
>>> Oops. This seems to affect more modules.
>>> Params::Validate with type => SCALAR seems to be broken.
>>> http://rt.cpan.org/NoAuth/ReportBug.html?Queue=Params%3A%3AValidate
>>>
>>> I have to go now, but will provide a patch soon.
>>> As workaround I would disable the validation in DateTime::Locale::_register
>>> but this also doesn't work as expected.
>>>
>>>if (! defined $p{id} or !$id) {
>>># cygperl5 error in Params::Validate?
>>>#warn "Broken Params::Validate. Given ".join(",",@_);
>>>$p{id} = $_[0];
>>>$p{en_language} = $_[1];
>>>my @keys = qw(en_script en_territory en_variant native_language
>>> native_script native_territory native_variant class replace);
>>>for my $i (2 .. @_) {
>>>$p{$keys[$i]} = $_[$i];
>>>}
>>>}
>>
>> Update on this issue:
>> As you can see, there's only one machine with this error, which is my laptop.
>> http://cpantesters.perl.org/show/DateTime-Locale.html#DateTime-Locale-0.4001
>> My normal devel machine passed the DateTime::Locale test, which is weird.
>> I also pass the Params::Validate test on my laptop, which is weirder,
>> because this fails for DateTime::Locale on my laptop.
>>
>> Anyway, until I find out the differences between my laptop and my
>> devel machine,
>> the short summary:
>>
>> Params::Validate fails in an BEGIN block, in a type => SCALAR check only on
>> certain machines with 5.10.0 patch 34065 on Cygwin. (Tested only
>> release and patch 34065).
>> Reproducible with DateTime::Locale.
>> Within the debugger everything works ok. (Probably because of the BEGIN
>> block)
>> The other DateTime::Locale reports show no clue.
>> There's a Darwin report on the same patchlevel which passed.
>>
>> Within DateTime-Locale-0.4001 after make
>> even perl -Mblib -cw t/01basic.t fails with the same errors.
>>
>> Moving the register call from BEGIN to INIT also does not help.
>
> The adhoc workaround for perl-5.10.0-5 is to move away the Validate XS module:
>
> mv
> /usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Params/Validate/Validate.dll \
> /usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/Params/Validate/_Validate.dll
>
> Now it works, because Params::Validate has a slower pure-perl fallback.
I've analyzed the symbols in the dll's and found the explanation and
solution for this update problems. p5p and module authors need not to
be concerned. It's a simple cygwin perl update problem.
In short:
All old perl-5.10.0-4 generated binary site_perl modules need to be
recompiled with perl-5.10.0-5.
They are not ABI cross-compatible with the new vendor and archlib modules.
Explanation:
perl-5.10.0-5 is based on patchlevel 34065, perl-5.10.0-4 was based on
plain 5.10.0 with a lot of patches.
perl-5.10.0-5 adds a new utf8 handling of strings via a new
newSVpvn_flags function
sv.h: #define newSVpvn_utf8(s, len, u) newSVpvn_flags((s), (len), (u)
? SVf_UTF8 : 0)
perl-5.10.0-4 does not contain newSVpvn_utf8 nor newSVpvn_flags.
So any new XS module using strings may not call an old perl-5.10.0-4 dll, which
does not contain the _utf8 and _flags functions.
Solution:
# delete all old site packages with dll's and reinstall them
for pack in $(find /usr/lib/perl5/site_perl/5.10/i686-cygwin/auto \
-name .packlist \! -newer /bin/perl.exe);
do
grep .dll $pack && rm -f $(cat $pack)
done | \
perl -MCPAN -ne'
s|/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/(.+?)/\w+\.dll$|$1|;
s|/|::|g; push @p, $_; END {install(@p) }'
should recompile them all.
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: perl-5.10.0-4 -> perl-5.10.0-5 site_perl update needed
2008/7/10 Reini Urban:
> I've analyzed the symbols in the dll's and found the explanation and
> solution for this update problems. p5p and module authors need not to
> be concerned. It's a simple cygwin perl update problem.
>
> In short:
> All old perl-5.10.0-4 generated binary site_perl modules need to be
> recompiled with perl-5.10.0-5.
> They are not ABI cross-compatible with the new vendor and archlib modules.
>
> Explanation:
> perl-5.10.0-5 is based on patchlevel 34065, perl-5.10.0-4 was based on
> plain 5.10.0 with a lot of patches.
>
> perl-5.10.0-5 adds a new utf8 handling of strings via a new
> newSVpvn_flags function
> sv.h: #define newSVpvn_utf8(s, len, u) newSVpvn_flags((s), (len), (u)
> ? SVf_UTF8 : 0)
> perl-5.10.0-4 does not contain newSVpvn_utf8 nor newSVpvn_flags.
>
> So any new XS module using strings may not call an old perl-5.10.0-4 dll,
> which
> does not contain the _utf8 and _flags functions.
Well, newSVpvn_utf8 is just a macro.
> Solution:
> # delete all old site packages with dll's and reinstall them
> for pack in $(find /usr/lib/perl5/site_perl/5.10/i686-cygwin/auto \
> -name .packlist \! -newer /bin/perl.exe);
> do
> grep .dll $pack && rm -f $(cat $pack)
> done | \
> perl -MCPAN -ne'
> s|/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/(.+?)/\w+\.dll$|$1|;
> s|/|::|g; push @p, $_; END {install(@p) }'
>
> should recompile them all.
Oops, I forgot the final \n. chomp is needed.
Removing the .packlist would also be good.
This is the script, needed if you installed binary cpan packages with
-4 or older 5.10 packages
~/bin/perl-site-update-4
for pack in $(find /usr/lib/perl5/site_perl/5.10/i686-cygwin/auto \
-name .packlist \! -newer /bin/perl.exe);
do
grep .dll $pack && rm -f $(cat $pack) && rm -f $pack
done | \
perl -MCPAN -ne'
s|/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/(.+?)/\w+\.dll$|$1|;
s|/|::|g; chomp; push @p, $_; END {install(@p) }'
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Updating cygwin from a remote shell?
Hi there, Thanks, all, for the responses. On Wed, 9 Jul 2008 Andrew DeFaria wrote: > > rdesktop to connect to their Windows 2000 server and I'm not _very_ > > careful how I close down the rdesktop session then the server crashes. > > I've never seen this happen at all. By definition, any user application > able to crash a system is a bug. You got a bug there. It should be fixed. Agreed. :) > > If there are any tips for a safer way of connecting to a Windows 2000 > > server to do routine upgrades of Cygwin and other remote admin that I > > can't do using ssh, I'd be very happy to hear them. > > You could try VNC. Thanks, I'll give it a try > [...] RDP is nicer and much faster then VNC. VNC, however, works [...] I'll be happy if it just does that. :) > Then again, rdesktop crashing a server is odd. Is it actually > dumping core? Yes. But I don't want to hijack this thread by going on to debug that particular problem. :) Actually I'm not sure that it's rdesktop itself that's causing the crash. It will crash if I do other things remotely using rdesktop, such as paging rapidly through the system log using the log viewer from 'administrative tools'. It isn't something that I can easily investigate, largely because I'd be lynched by an angry mob from the welding shop. FWIW I've never caused a crash using Cygwin+ssh, and that's how I try to do most of what I need to do. -- 73, Ged. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
mod_perl2 build problems
Dear list, I am trying to build mod_perl2 in my Cygwin environment, and the build stops at the following: make[3]: Entering directory `/usr/src/.cpan/build/mod_perl-2.0.4-Y5Qjqi/WrapXS/APR/ThreadRWLock' rm -f ../../../blib/arch/auto/APR/ThreadRWLock/ThreadRWLock.dll g++ --shared -Wl,--enable-auto-import -Wl,--export-all-symbols -Wl,--stack,8388608 -Wl,--enable-auto-image-base -L/usr/local/lib ThreadRWLock.o -Wl,--enable-auto-import -Wl,--export-all-symbols -Wl,--stack,8388608 -Wl,--enable-auto-image-base -L/usr/local/lib -o ../../../blib/arch/auto/APR/ThreadRWLock/ThreadRWLock.dll \ /usr/lib/perl5/5.10/i686-cygwin/CORE/libperl.dll.a -L/usr/src/.cpan/build/mod_perl-2.0.4-Y5Qjqi/blib/arch/auto/libaprext -laprext -L/usr/lib/perl5/5.10/i686-cygwin/CORE -lperl -L/usr/src/.cpan/build/mod_perl-2.0.4-Y5Qjqi/src/modules/perl -lhttpd2core -L/usr/lib -laprutil-1 -lgdbm -ldb-4.2 -lexpat -liconv -L/usr/lib -L/usr/lib -lapr-1 -lcrypt \ ThreadRWLock.o:ThreadRWLock.c:(.text+0xa0): undefined reference to `_apr_thread_rwlock_create' ThreadRWLock.o:ThreadRWLock.c:(.text+0x297): undefined reference to `_apr_thread_rwlock_destroy' ThreadRWLock.o:ThreadRWLock.c:(.text+0x3da): undefined reference to `_apr_thread_rwlock_pool_get' ThreadRWLock.o:ThreadRWLock.c:(.text+0x57d): undefined reference to `_apr_thread_rwlock_rdlock' ThreadRWLock.o:ThreadRWLock.c:(.text+0x77d): undefined reference to `_apr_thread_rwlock_tryrdlock' ThreadRWLock.o:ThreadRWLock.c:(.text+0x97d): undefined reference to `_apr_thread_rwlock_trywrlock' ThreadRWLock.o:ThreadRWLock.c:(.text+0xb7d): undefined reference to `_apr_thread_rwlock_unlock' ThreadRWLock.o:ThreadRWLock.c:(.text+0xd7d): undefined reference to `_apr_thread_rwlock_wrlock' collect2: ld returned 1 exit status make[3]: *** [../../../blib/arch/auto/APR/ThreadRWLock/ThreadRWLock.dll] Error 1 make[3]: Leaving directory `/usr/src/.cpan/build/mod_perl-2.0.4-Y5Qjqi/WrapXS/APR/ThreadRWLock' I have tried googling for this error, without finding a single hit, and I have tried finding out which lib should provide the references above. Would anybody on the list be able to point me in the right direction at all? Best regards Jan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Event viewer application error?
Larry Hall (Cygwin) presented the following explanation : Kevin M wrote: Hello, I'm getting this error. /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: /usr/sbin/cron: PID 2784: (CRON) error (can't switch user context). I checked and found something that said to add execute permsisions to the cygwin1.dll and give permissions to /etc/cron.d. This has not worked if anybody has any ideas I would apprcieate it. I have no idea where to put the /AUXSOURCE= flag and also don't know what value it is looking for. This would be helpful: Problem reports: http://cygwin.com/problems.html Or at least who the 'cron' service is running as. My guess is that when you installed cron, you chose to run it as yourself or some other unprivileged (including 'Administrator') user. Windows services cannot switch user contexts unless they use a special privileged account (SYSTEM on XP or older systems). That's why you get the message. The solution? Reinstall it and let it run under a privileged account. Hello, After all of my struggles getting this to work I have finally got it. What I did was chmod all of the files in my cywin install and took ownership with the same domain admin account that cron is using and it worked! Kevin M (A true work in progress!) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: scheme implementations for cygwin
Great! Care to ITP them? I would review them. We would just need debian links. At least bigloo and slib should be in the official distro. 2008/7/9 Nathan Thern: > I have compiled several scheme implementations natively on cygwin. > I've put them (with a couple of other packages I have created) in a > repository at http://www.liquid.spod.org/~nthern/cygwin/ > They are mostly untested. If the REPL works and some simple scheme > codes run, I have put it in. Feedback is welcome. > > If anyone else has successful ports that they would like posted, I > will accept them if they are cygport packages that I can recompile on > my own from independently downloaded sources. I am especially > interested in language implementations and mathematical/scientific > projects. > > Scheme implementations: > bigloo Aren't there some more requires missing? You have only libgmp, which should be libgmp3. I would also expect libsqlite3_0 srfi openssl CONF_ARGS --enable-calendar --enable-fthread --enable-gstreamer \ --enable-mail --enable-multimedia --enable-pkgcomp --enable-pkglib \ --enable-pthread --enable-sqlite --enable-srfi1 --enable-ssl \ --enable-web > chicken I would exclude the generated files from the src patch: DIFF_EXCLUDES="chicken-config.h chicken-defaults.h" > gauche This is a mess. The binary libs are in /usr/share/gauche/0.8.13/i686-pc-cygwin/*.dll, they should go to /usr/lib/gauche/0.8.13/ The linux default was almost fine. The headers from /usr/share/gauche/0.8.13/include/gauche.h should go to /usr/include/gauche/ The scm libs files: Well they can stay at /usr/share/gauche/0.8.13/lib but /usr/lib/gauche/0.8.13/lib would be better The DLL /usr/bin/libgauche.dll was forced with this name, so you could have used the better name cyggauche0.dll > ikarus Same libgmp issue as with bigloo: libgmp3. /usr/bin/scheme-script.exe cries for a name clash with other schemes. Is this really kosher? > ksi The si/ksi_sign.c patch is not kosher. +//#if defined(SIGIO) && !defined(sun) +//# define INOUT_BY_SIGIO 1 +//#else => /* */ for gcc files. // only for g++ files. > plt Whow! collects/setup/variant.ss: [exe (case (system-type) [(windows) "MzScheme.exe"] -[else "mzscheme"])]) +[else "mzscheme.exe"])]) doesn't look to good. (system-type) should return 'cygwin, and the switch should be [(windows cygwin) "MzScheme.exe"] IMHO. This can be accepted upstream then with the rest of the src.patch, which looks fine. > rhizome The README contains a typo: "it never makes recurseive call" > scheme48 This is included in scsh, but having it seperate helps. > scm > slib > stk > stklos > sxm > Other stuff: > gifsicle > libffi libffi-3.0.0-1 was already at my contrib site. This builds OOTB anyway. > omake > remake Ah, remake again. Good. I have it as makedb somewhere. remake seems to be the official name now. I miss ghc ( Glasgow Haskell Compiler ), slime, ecl, scm ( Scheme in Javascript :) Can you put the cygport files also somewhere, so I don't have to download all the sources. Anyway, I did it now. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Perl-5.10 on a fresh install reports unable to remap Glob.dll
2008/7/9 Dave Wombat: > On Wed, Jul 9, 2008 at 9:51 AM, Reini Urban <[EMAIL PROTECTED]> wrote: >> Dave Wombat schrieb: >>> >>> I did a fresh install of Cygwin on a Vista box. I needed to add some >>> Perl modules so I ran >>> Perl -MCPAN -e shell >>> >>> After the install began I got errors about remap. Scanning the >>> archives showed that "rebase" >>> would help. Further scanning shows that "rebase" is built into >>> install and no longer directly available. >> >> This is wrong. rebaseall is still required, and for perl very likely. >> I did a fresh rebaseall at base 0x5200 onwards, but there are some still >> some clashes. >> >> Install the rebase package and follow the instructions in its README. In >> short: kill all bash processes and run rebaseall from ash >> -- >> Reini Urban >> http://phpwiki.org/ http://murbreak.at/ > > Still no happiness. I followed the instructions to best of my ability and > got: > > $ exec /bin/ash > \[\e]0;[EMAIL PROTECTED] \[\e[33m\]\w\[\e[0m\]\n\$ The cure for this problem is unset PS1 > $ rebaseall > ReBaseImage (/usr/bin/cygiconv-2.dll) failed with last error = 6 Be sure that cygiconv-2.dll is writable. $ chmod +w /bin/*.dll > \[\e]0;[EMAIL PROTECTED] \[\e[33m\]\w\[\e[0m\]\n\$ > \[\e]0;[EMAIL PROTECTED] \[\e[33m\]\w\[\e[0m\]\n\$ ps -ef > UID PIDPPID TTY STIME COMMAND > wombat8096 1 con 10:09:38 /usr/bin/ash > wombat 80248096 con 10:11:24 /usr/bin/ps > > So only ash is running. I'm about to reboot to see if that bit of voodoo > helps. Hmm. ps -ef should have shown all active processes (also services), but maybe there are hidden ones which you could detect with procexp from sysinternals.com -- Reini Urban http://phpwiki.org/ http://murbreak.at/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Perl-5.10 on a fresh install reports unable to remap Glob.dll
On Wed, 9 Jul 2008, Dave Wombat wrote: Still no happiness. I followed the instructions to best of my ability and got: $ exec /bin/ash \[\e]0;[EMAIL PROTECTED] \[\e[33m\]\w\[\e[0m\]\n\$ rebaseall ReBaseImage (/usr/bin/cygiconv-2.dll) failed with last error = 6 \[\e]0;[EMAIL PROTECTED] \[\e[33m\]\w\[\e[0m\]\n\$ \[\e]0;[EMAIL PROTECTED] \[\e[33m\]\w\[\e[0m\]\n\$ ps -ef UID PIDPPID TTY STIME COMMAND wombat8096 1 con 10:09:38 /usr/bin/ash wombat 80248096 con 10:11:24 /usr/bin/ps So only ash is running. I'm about to reboot to see if that bit of voodoo helps. Instructions I found on the web last night, I forget exact URLs, when I had problems with my CPAN under cygwin, were essentially: Close all cygwin windows Get rid of any processes left running if any Go to the Run command window (Eg press Windows+R) type in "C:\cygwin\bin\ash.exe" When the window comes up put in /bin/rebaseall This overcame the main problem with my system, and allowed, after a lot more compiling, to get things working. I found that my Cygwin install had more missing than I thought, and had to add make, gcc, and a few other things (I forget now) so I threw in flex, bison, and a few other dev tools for good measure. You may not be in that position. In the hope that this helps you, Hugh -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Problems installing Cygwin
Hello. I have used Cygwin since the year 2000, possibly 1999. Throughout the years I have had no problem installing and using my Cygwin installation; first on Win98, WinNt, Windows 2000, and Windows = XP. This year however I have not been able to achieve a good installation of = Cygwin. even though the steps I have taken are exactly the same ones I = used in the past: From the "setup.exe" program, using either "Install directly from the Internet" (with direct connection), or Downloading it first, then installing from a local directory. What I get are problems with the post-install scripts, which often hang there, doing nothing. I am working in XP/SP3 now. Most recently the post-install scripts seem to have run fine, and the installation was complete, I attempted to start Cygwin. I even took the precaution of creating the password and group files with the mkpasswd and mkgroup programs, with the commands: $ mkpasswd -l -g > /etc/passwd $ mkgroup -l > /etc/group I have also made sure my home directory in the Windows environment was set to HOME=C:\cygwin\home\baz and that the CYGWIN environment variable was set to: CYGWIN=ntsec binmode tty glob (I also tried with "nontsec") Having done this, I can press the "Cygwin" icon and get a command console that LOOKS like Cygwin, but the directory I get places in is /usr/bin, and there is not even a default path, so that I have to type in things like "/bin/ls" or "/bin/mount". Doing a "/bin/bash --login -i" has the same effect, as do all attempt to start the program with Cygwin.bat from a cmd.exe prompt. I do not know if I have missed some crucial and recent change, or what. The same installation process used to work just fine. This year (2008), I have only had the non-success described above. Please help if you can. Bryan Zimmer baz58 (at) comcast dot net -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Problems installing Cygwin
Bryan A. Zimmer wrote: there is not even a default path Perhaps your /etc/profile is damaged. If you open it in a text editor and it looks okay to you, diff it against /etc/defaults/etc/profile, that being the version that's installed when the Cygwin package that owns this file (dunno what it is off the top of my head) sees that it isn't already present. If it's present, it gets left alone on the theory that you changed it for a good reason, so damage won't be corrected. Alternately, you can do a complete uninstall: http://cygwin.com/faq/faq-nochunks.html#faq.setup.uninstall-all and then reinstall. This will ensure a clean slate, at the cost of losing any customizations you've made to Cygwin over the past 8 years. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Problems installing Cygwin
Bryan A. Zimmer wrote: Hello. I have used Cygwin since the year 2000, possibly 1999. Throughout the years I have had no problem installing and using my Cygwin installation; first on Win98, WinNt, Windows 2000, and Windows = XP. This year however I have not been able to achieve a good installation of = Cygwin. even though the steps I have taken are exactly the same ones I = used in the past: From the "setup.exe" program, using either "Install directly from the Internet" (with direct connection), or Downloading it first, then installing from a local directory. What I get are problems with the post-install scripts, which often hang there, doing nothing. I am working in XP/SP3 now. Most recently the post-install scripts seem to have run fine, and the installation was complete, I attempted to start Cygwin. I even took the precaution of creating the password and group files with the mkpasswd and mkgroup programs, with the commands: $ mkpasswd -l -g > /etc/passwd $ mkgroup -l > /etc/group I have also made sure my home directory in the Windows environment was set to HOME=C:\cygwin\home\baz and that the CYGWIN environment variable was set to: CYGWIN=ntsec binmode tty glob (I also tried with "nontsec") Having done this, I can press the "Cygwin" icon and get a command console that LOOKS like Cygwin, but the directory I get places in is /usr/bin, and there is not even a default path, so that I have to type in things like "/bin/ls" or "/bin/mount". Doing a "/bin/bash --login -i" has the same effect, as do all attempt to start the program with Cygwin.bat from a cmd.exe prompt. I do not know if I have missed some crucial and recent change, or what. The same installation process used to work just fine. This year (2008), I have only had the non-success described above. Please help if you can. Perhaps a problem report with the standard requested details as requested at the link below would yield some clues? Perhaps you'll notice something too in the preparation of the report. Problem reports: http://cygwin.com/problems.html -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Problems installing Cygwin
Bryan A. Zimmer wrote: > > Most recently the post-install scripts seem to have run fine, and the > installation was complete, I attempted to start Cygwin. I even took the > precaution of creating the password and group files with the mkpasswd > and mkgroup programs, with the commands: > > $ mkpasswd -l -g > /etc/passwd > $ mkgroup -l > /etc/group > > I have also made sure my home directory in the Windows environment was set > to HOME=C:\cygwin\home\baz and that the CYGWIN environment variable was > set to: CYGWIN=ntsec binmode tty glob (I also tried with "nontsec") > > Having done this, I can press the "Cygwin" icon and get a command console > that LOOKS like Cygwin, but the directory I get places in is /usr/bin, and > there is not even a default path, so that I have to type in things like > "/bin/ls" > or "/bin/mount". > > Doing a "/bin/bash --login -i" has the same effect, as do > all attempt to start the program with Cygwin.bat from a cmd.exe prompt. > > I do not know if I have missed some crucial and recent change, or what. > The same installation process used to work just fine. This year (2008), > I have only had the non-success described above. > I need some more information to help: First, the output of `/bin/mount`, which is a list of all the mountpoints on your system. The most common reason that the shell can't find commands in the PATH is that the mount table has gotten messed up. Second, the output of `/bin/env`, which is a dump of your environment variables. Any nuber of problems result from one or more of these being messed up. Third, the output of `/bin/uname -a`, which is the version information of your Cygwin installation. This is generally useful so we know how it's *supposed* to work. Lastly, please confirm or correct the following info: - Your base install directory is "C:\Cygwin" - The installer (setup.exe) finished without errors -- Sam Hanes Send list replies to ! -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Problems installing Cygwin
I (Sam Hanes) wrote: > > I need some more information to help: > > First, the output of `/bin/mount`, which is a list of all the > mountpoints on your system. The most common reason that the shell > can't find commands in the PATH is that the mount table has gotten > messed up. > > Second, the output of `/bin/env`, which is a dump of your environment > variables. Any nuber of problems result from one or more of these > being messed up. > > Third, the output of `/bin/uname -a`, which is the version information > of your Cygwin installation. This is generally useful so we know how > it's *supposed* to work. > All of the data I requested and more is provided by `cygcheck -s -v -r`, as suggested in the Cygwin problem reporting guidelines at "http://www.cygwin.com/problems.html";. Thanks to Larry Hall for pointing this out. Please run `/bin/cygcheck -svr > cygcheck.out` and attach "cygcheck.out" to a reply. DO NOT put the output in the body of your message because it is extremely long. I do still need you to confirm or correct the following info: - Your base install directory is "C:\Cygwin" - The installer (setup.exe) finished without errors -- Sam Hanes Send list replies to -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Problems installing Cygwin
The postinstall scripts might not have run correctly, to really see what happened with them take a look at /var/log/setup.log Eric - Original Message From: Bryan A. Zimmer <[EMAIL PROTECTED]> To: cygwin@cygwin.com Sent: Thursday, July 10, 2008 10:47:32 AM Subject: Problems installing Cygwin Hello. I have used Cygwin since the year 2000, possibly 1999. Throughout the years I have had no problem installing and using my Cygwin installation; first on Win98, WinNt, Windows 2000, and Windows = XP. This year however I have not been able to achieve a good installation of = Cygwin. even though the steps I have taken are exactly the same ones I = used in the past: From the "setup.exe" program, using either "Install directly from the Internet" (with direct connection), or Downloading it first, then installing from a local directory. What I get are problems with the post-install scripts, which often hang there, doing nothing. I am working in XP/SP3 now. Most recently the post-install scripts seem to have run fine, and the installation was complete, I attempted to start Cygwin. I even took the precaution of creating the password and group files with the mkpasswd and mkgroup programs, with the commands: $ mkpasswd -l -g > /etc/passwd $ mkgroup -l > /etc/group I have also made sure my home directory in the Windows environment was set to HOME=C:\cygwin\home\baz and that the CYGWIN environment variable was set to: CYGWIN=ntsec binmode tty glob (I also tried with "nontsec") Having done this, I can press the "Cygwin" icon and get a command console that LOOKS like Cygwin, but the directory I get places in is /usr/bin, and there is not even a default path, so that I have to type in things like "/bin/ls" or "/bin/mount". Doing a "/bin/bash --login -i" has the same effect, as do all attempt to start the program with Cygwin.bat from a cmd.exe prompt. I do not know if I have missed some crucial and recent change, or what. The same installation process used to work just fine. This year (2008), I have only had the non-success described above. Please help if you can. Bryan Zimmer baz58 (at) comcast dot net -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation:http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: scheme implementations for cygwin
On Thu, Jul 10, 2008 at 8:46 AM, Reini Urban <[EMAIL PROTECTED]> wrote: > Great! Care to ITP them? They're all a kinda rough. A little background here: a while ago I compiled as many scheme implementations as I could for cygwin. When cygport came out, I even made a few packages, but I never ran genini, or tried them with setup.exe. In general, my MO was: If it worked for me, I was done. When my work computer (the whole reason I use cygwin) was upgraded, I grabbed as much of my scheme work as I could. Realizing the foolishness of not creating a personal repo, I started one. Then I decided to mirror my personal repo to a web URL and report it to the mailing list. What does ITP stand for, anyway? > I would review them. We would just need debian links. debian links?? I use debian at home, but what do you mean here? > At least bigloo and slib should be in the official distro. slib is in Yaakov's cygwin ports, but the version number is too low to compile the latest SCM. His README states that later slib versions don't work with gnucash (which is not in cygwin ports). Yaakov, are you planning to release gnucash? And will a recent slib really conflict with that? bigloo, chicken, Gambit-C, PLT, & SCM are all major free scheme implementations that are worthy of the official distro. I am working on Gambit-C now. > 2008/7/9 Nathan Thern: >> bigloo > Aren't there some more requires missing? > You have only libgmp, which should be libgmp3. > I would also expect libsqlite3_0 srfi openssl OK >> chicken > I would exclude the generated files from the src patch: > DIFF_EXCLUDES="chicken-config.h chicken-defaults.h" OK. DIFF_EXCLUDES will clean up my gauche patch too. chicken is my favorite scheme & the build is real smooth on cygwin. If I ITP, chicken will be first. >> gauche > This is a mess. Will fix. I think I mimicked the args cygport passes to configure. Removing them will be a start. > The DLL /usr/bin/libgauche.dll was forced with this name, > so you could have used the better name cyggauche0.dll forced? My patch to the gauche source was very minimal. Do I have to use libtool to create cygfooX.dll? BTW, what's with all the variations on the end of cygfoo? I've seen cygfoo.dll, cygfoo0.dll, cygfoo-0.dll and cygfoo-5.dll to name a few. >> ikarus > Same libgmp issue as with bigloo: libgmp3. > /usr/bin/scheme-script.exe cries for a name clash with other schemes. > Is this really kosher? OK >> ksi > The si/ksi_sign.c patch is not kosher. OK >> plt > Whow! Yeah, PLT is a beast. > (system-type) should return 'cygwin I agree the patch will never fly outside cygwin. I believe I was forced to patch (system-type) to return 'unix. It has to do with the build system only considering cygwin to be a substitute for msys & wanting to build win32 executables. I have to fake out the build system to believe it's building on generic unix to get a POSIX/cygwin aware result. > I miss ghc ( Glasgow Haskell Compiler ) Working on it. Pretty rough going (reference the comment about the PLT build system & inflate to your worst nightmare.) > scm ( Scheme in Javascript :) not scm, I think. jsScheme? > Can you put the cygport files also somewhere Nah, most of these fail to build without the source patches anyway. Just download the source packages & throw out what you don't want. regards, NT -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: scheme implementations for cygwin
Nathan Thern wrote: What does ITP stand for, anyway? http://cygwin.com/acronyms/#ITP Search for that in the subject line of some recent messages to see what an ITP message normally looks like, then do that. :) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: perl-5.10.0-4 -> perl-5.10.0-5 site_perl update needed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Reini Urban wrote: | In short: | All old perl-5.10.0-4 generated binary site_perl modules need to be | recompiled with perl-5.10.0-5. | They are not ABI cross-compatible with the new vendor and archlib modules. Say WHAT? I need to recompile all binary modules in Ports?!?!? Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkh2cNoACgkQpiWmPGlmQSOIewCfYyiRYrLNLVg2DYEw3m3avo4b Z20An0l2s9waHF89WWIidTQiNKuYHkaW =f4de -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: mod_perl2 build problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jan-Aage Frydenbø-Bruvoll wrote: | I have tried googling for this error, without finding a single hit, and | I have tried finding out which lib should provide the references above. | Would anybody on the list be able to point me in the right direction at | all? mod_perl 2.0.4 assumes a threaded libapr, which Cygwin does not provide. ~ Check out Ports CVS for details: http://cygwin-ports.cvs.sourceforge.net/cygwin-ports/ports/apache/mod_perl/ Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkh2cZcACgkQpiWmPGlmQSMYZQCeKbQPjHoB6gveJNOEVlTyV3Ct /1UAoKzpm5v1KGyjgBaN0qQ1zvtJ3Nje =77Tb -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: binutils: ld --export-dynamic
On Thu, Jul 03, 2008 at 09:39:59AM -0500, Yaakov (Cygwin Ports) wrote: > While you're waiting for the binutils list to get back to you, here's > another binutils issue. This is not a regression in 2.18, but rather a > longstanding difference in Cygwin behaviour versus Linux. > > When linking a program with -Wl,--export-dynamic, no symbols are > exported. The problem arises when the executable needs to either dlopen > itself, or when it has plugins which are "linked" against it. Both > scenarios are not uncommon, particularly with GNOME software. > > While this does work on Linux, it does not work on Cygwin with > - --export-dynamic; only --export-all-symbols, an i386PE-specific flag, > will accomplish this. > > I've attached a test case; it's a simplified version of the test used in > LT_SYS_DLOPEN_SELF (prev. AC_LIBTOOL_DLOPEN_SELF): > > $ gcc -o test.exe dlopen-self.c && ./test.exe > status = 0 > > $ gcc -Wl,--export-dynamic -o test.exe dlopen-self.c && ./test.exe > status = 0 > > $ gcc -Wl,--export-all-symbols -o test.exe dlopen-self.c && ./test.exe > status = 1 > > Running 'objdump -p test.exe' will also show that the export table is > only generated in the last case. > > I would appreciate your input on this issue. It's probably best to report general binutils problems like this to the binutils mailing list. Someone like Danny Smith may know how to fix this quickly. You could also create a bugzilla entry for this since it seems like a bug. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: perl-5.10.0-4 -> perl-5.10.0-5 site_perl update needed
On Thu, 10 Jul 2008, Reini Urban wrote:
> I've analyzed the symbols in the dll's and found the explanation and
> solution for this update problems. p5p and module authors need not to
> be concerned. It's a simple cygwin perl update problem.
>
> In short:
> All old perl-5.10.0-4 generated binary site_perl modules need to be
> recompiled with perl-5.10.0-5.
This should not be true: if the modules were compiled with 5.10.0-4, then
they should work with 5.10.0-5.
> They are not ABI cross-compatible with the new vendor and archlib modules.
>
> Explanation:
> perl-5.10.0-5 is based on patchlevel 34065, perl-5.10.0-4 was based on
> plain 5.10.0 with a lot of patches.
>
> perl-5.10.0-5 adds a new utf8 handling of strings via a new
> newSVpvn_flags function
> sv.h: #define newSVpvn_utf8(s, len, u) newSVpvn_flags((s), (len), (u)
> ? SVf_UTF8 : 0)
> perl-5.10.0-4 does not contain newSVpvn_utf8 nor newSVpvn_flags.
>
> So any new XS module using strings may not call an old perl-5.10.0-4 dll,
> which
> does not contain the _utf8 and _flags functions.
So how do you end up with a site_perl compiled against 5.10.0-5, but
running with 5.10.0-4? You installed the new site_perl into an older
Perl installation?
> Solution:
> # delete all old site packages with dll's and reinstall them
> for pack in $(find /usr/lib/perl5/site_perl/5.10/i686-cygwin/auto \
> -name .packlist \! -newer /bin/perl.exe);
> do
> grep .dll $pack && rm -f $(cat $pack)
> done | \
> perl -MCPAN -ne'
> s|/usr/lib/perl5/site_perl/5.10/i686-cygwin/auto/(.+?)/\w+\.dll$|$1|;
> s|/|::|g; push @p, $_; END {install(@p) }'
>
> should recompile them all.
But that would compile them with 5.10.0-4 again, right. Wouldn't it be
better to replace your 5.10.0-4 dll with the 5.10.0-5 dll?
I guess I'm confused about how you ended up in this situation in the
first place.
Cheers,
-Jan
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
programming API to determine whether in "Cygwin environment"
My console program is built for native Windows (thus does not reply on cygwin1.dll). However, people may want to use it in a Cygwin environment and if they do I want it to behave in a suitably "Unixy" way. The obvious example is that when it prints out a pathname (which happens a lot) a Cygwin user would prefer to see it in Cygwin style, including forward slashes. So I'm looking for a boolean method which will allow a program to tell whether it was run from within a Cygwin shell. An environment variable would be fine as long as it's standard. In fact I see a number of env vars which would enable an educated guess but am wondering if there's a defined standard and safe way. TIA -- View this message in context: http://www.nabble.com/programming-API-to-determine-whether-in-%22Cygwin-environment%22-tp18395872p18395872.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: programming API to determine whether in "Cygwin environment"
On Thu, Jul 10, 2008 at 08:49:06PM -0700, Tony Last wrote: > >My console program is built for native Windows (thus does not reply on >cygwin1.dll). However, people may want to use it in a Cygwin environment and >if they do I want it to behave in a suitably "Unixy" way. The obvious >example is that when it prints out a pathname (which happens a lot) a Cygwin >user would prefer to see it in Cygwin style, including forward slashes. > >So I'm looking for a boolean method which will allow a program to tell >whether it was run from within a Cygwin shell. An environment variable would >be fine as long as it's standard. In fact I see a number of env vars which >would enable an educated guess but am wondering if there's a defined >standard and safe way. A PATH containing colons which weren't preceded by just a single alphabetic character would be a clue but it wouldn't be foolproof. A HOME environment variable with no colons and forward slashes would be another clue. I don't think there is a foolproof test, though. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: programming API to determine whether in 'Cygwin environment'
On Thu, July 10, 2008 10:06 pm, Christopher Faylor wrote: > On Thu, Jul 10, 2008 at 08:49:06PM -0700, Tony Last wrote: >> My console program is built for native Windows (thus does not reply on >> cygwin1.dll). >> >> So I'm looking for a boolean method which will allow a program to tell >> whether it was run from within a Cygwin shell. > > A PATH containing colons which weren't preceded by just a single > alphabetic character would be a clue but it wouldn't be foolproof. A HOME > environment variable with no colons and forward slashes would be another > clue. I don't think there is a foolproof test, though. Both HOME and PATH are translated by the time the non-cygwin program sees them, though?? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
