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
Re: C:\cygwin\bin\cyggcc_s-1.dll: Loaded to different address
On 12/04/2013 12:00 PM, bartels wrote: Hello People, Cygwin seems to have become very stable recently, which is a Good Thing for me. And then I saw this one: 0 [main] perl 10672 child_info_fork::abort: C:\cygwin\bin\cyggcc_s-1.dll: Loaded to different address: parent(0x32) != child(0x3A) What could be causing it? Please note that I understand that the ad-hoc solution is to run rebaseall. Unfortunately, that is not always possible. I am looking for the cause of the problem, so that I know how to prevent it. Or is the only answer to simply run rebaseall after installation? -- bartels -- 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
Il 12/4/2013 12:54 PM, bartels ha scritto: On 12/04/2013 12:00 PM, bartels wrote: Hello People, Cygwin seems to have become very stable recently, which is a Good Thing for me. And then I saw this one: 0 [main] perl 10672 child_info_fork::abort: C:\cygwin\bin\cyggcc_s-1.dll: Loaded to different address: parent(0x32) != child(0x3A) What could be causing it? the base address seems very low $ rebase -si |grep cyggcc_S /usr/bin/cyggcc_s-1.dll base 0x6465 size 0x0001f000 likely some other DLL is using the expected space for cyggcc_s-1.dll in the 0x6xxx adddress range. Please note that I understand that the ad-hoc solution is to run rebaseall. Unfortunately, that is not always possible. why ? Tricky sometime, but possible always. I am looking for the cause of the problem, so that I know how to prevent it. Or is the only answer to simply run rebaseall after installation? usually yes -- bartels Marco -- 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 12/04/2013 01:23 PM, marco atzeri wrote: Thanks for your reply. Please note that I understand that the ad-hoc solution is to run rebaseall. Unfortunately, that is not always possible. why ? Tricky sometime, but possible always. Well, not exactly impossible, but these are production machines that belong to a customer. It is not practical to ask them to kill all processes and run rebaseall when this happens. Not to mention that there should be a tracker process reporting the issue in the first place. I am looking for the cause of the problem, so that I know how to prevent it. Or is the only answer to simply run rebaseall after installation? usually yes If that is the case, then why is it not part of the installation? I do not understand why it happens on the one Windows 7 machine and not the other. - - Bartels -- 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
Il 12/4/2013 1:35 PM, bartels ha scritto: On 12/04/2013 01:23 PM, marco atzeri wrote: I am looking for the cause of the problem, so that I know how to prevent it. Or is the only answer to simply run rebaseall after installation? usually yes If that is the case, then why is it not part of the installation? currently, it is part of the installation /etc/postinstall/autorebase.bat.done $ cygcheck -f /etc/postinstall/autorebase.bat _autorebase-000444-1 so or last rebase went wrong or something else is using cyggcc_s.dll space I do not understand why it happens on the one Windows 7 machine and not the other. MS mistery ;-) what is the outcome of rebase -si |grep cyggcc_s ? rebase -si will also provide all colliding dll's; they are marked with a * please also follow http://cygwin.com/problems.html at cygcheck -s -v -r cygcheck.out - - Bartels Marco -- 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 Dec 4 14:53, bartels wrote: On 12/04/2013 02:11 PM, marco atzeri wrote: Il 12/4/2013 1:35 PM, bartels ha scritto: On 12/04/2013 01:23 PM, marco atzeri wrote: I am looking for the cause of the problem, so that I know how to prevent it. Or is the only answer to simply run rebaseall after installation? usually yes If that is the case, then why is it not part of the installation? currently, it is part of the installation /etc/postinstall/autorebase.bat.done $ cygcheck -f /etc/postinstall/autorebase.bat _autorebase-000444-1 Your attached cygcheck output claims something else. The rebase version should be updated to 4.4.1 as well. Okay, thanks. I missed that. It did run, I suppose: Yes, but... $ cat /etc/postinstall/autorebase.bat.done @echo off rem Postinstall scripts are always started from the Cygwin root dir rem so we can just call dash from here path .\bin;%path% dash /bin/rebaseall -p so or last rebase went wrong or something else is using cyggcc_s.dll space It is intermittent. Does that help? I do not understand why it happens on the one Windows 7 machine and not the other. MS mistery ;-) Yikes. Not really funny, but still funny. what is the outcome of rebase -si |grep cyggcc_s ? Ah, that is an interesting one: $ rebase -si rebase: failed to open rebase database /etc/rebase.db.i386: No such file or directory ...this here means that rebase never created the database, which in turn could point to rebase crashing or not having sufficient privileges on /etc. Something like that. What happens if you stop all Cygwin processes, including any service you installed, then start dash, make sure you're in /bin, and then call `./rebaseall -p'. Any helpful output? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpdlbHOKC2xm.pgp Description: PGP signature
Re: C:\cygwin\bin\cyggcc_s-1.dll: Loaded to different address
On 12/04/2013 03:23 PM, Corinna Vinschen wrote: On Dec 4 14:53, bartels wrote: On 12/04/2013 02:11 PM, marco atzeri wrote: Il 12/4/2013 1:35 PM, bartels ha scritto: On 12/04/2013 01:23 PM, marco atzeri wrote: I am looking for the cause of the problem, so that I know how to prevent it. Or is the only answer to simply run rebaseall after installation? usually yes If that is the case, then why is it not part of the installation? currently, it is part of the installation /etc/postinstall/autorebase.bat.done $ cygcheck -f /etc/postinstall/autorebase.bat _autorebase-000444-1 Your attached cygcheck output claims something else. The rebase version should be updated to 4.4.1 as well. Don't think there is a mismatch: that output was Marco's, not mine. Unless I misunderstand . . . Ah, that is an interesting one: $ rebase -si rebase: failed to open rebase database /etc/rebase.db.i386: No such file or directory ...this here means that rebase never created the database, which in turn could point to rebase crashing or not having sufficient privileges on /etc. Something like that. What happens if you stop all Cygwin processes, including any service you installed, then start dash, make sure you're in /bin, and then call `./rebaseall -p'. Any helpful output? How about this; sure looks like something is wrong: ./rebaseall -p gzip: stdin: unexpected end of file Thing is that I need to work with a fixed collection of packages. The rolling release offered by the installer is fine, but not exactly suited for a controlled release to an unsuspecting user. So, perhaps I made a mistake, or there is some unfortunate combination of versions. Anyway, I will upgrade my collection bundle and try again. Unless the error message immediately rings a bell for you . . . Thanks, -- Bartels -- 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 Dec 4 17:41, bartels wrote: On 12/04/2013 03:23 PM, Corinna Vinschen wrote: On Dec 4 14:53, bartels wrote: On 12/04/2013 02:11 PM, marco atzeri wrote: Il 12/4/2013 1:35 PM, bartels ha scritto: On 12/04/2013 01:23 PM, marco atzeri wrote: I am looking for the cause of the problem, so that I know how to prevent it. Or is the only answer to simply run rebaseall after installation? usually yes If that is the case, then why is it not part of the installation? currently, it is part of the installation /etc/postinstall/autorebase.bat.done $ cygcheck -f /etc/postinstall/autorebase.bat _autorebase-000444-1 Your attached cygcheck output claims something else. The rebase version should be updated to 4.4.1 as well. Don't think there is a mismatch: that output was Marco's, not mine. Unless I misunderstand . . . http://cygwin.com/ml/cygwin/2013-12/msg00085.html was your mail, so it's kind of hard to imagine that the attached cygcheck output was Marco's. Check the version numbers. It's _autorebase-000425-1 and rebase-4.4.0-1 in the cygcheck output. Ah, that is an interesting one: $ rebase -si rebase: failed to open rebase database /etc/rebase.db.i386: No such file or directory ...this here means that rebase never created the database, which in turn could point to rebase crashing or not having sufficient privileges on /etc. Something like that. What happens if you stop all Cygwin processes, including any service you installed, then start dash, make sure you're in /bin, and then call `./rebaseall -p'. Any helpful output? How about this; sure looks like something is wrong: ./rebaseall -p gzip: stdin: unexpected end of file Yes, something is wrong. Looks like you removed the /etc/setup directory or the contents of that dir. The content is created and maintained by the setup installer and rebaseall needs the information. Don't play games with the files under /etc unless you want to break your installation. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpyW85g3dZhr.pgp Description: PGP signature
Re: C:\cygwin\bin\cyggcc_s-1.dll: Loaded to different address
On 12/04/2013 05:53 PM, Corinna Vinschen wrote: On Dec 4 17:41, bartels wrote: On 12/04/2013 03:23 PM, Corinna Vinschen wrote: On Dec 4 14:53, bartels wrote: On 12/04/2013 02:11 PM, marco atzeri wrote: Il 12/4/2013 1:35 PM, bartels ha scritto: On 12/04/2013 01:23 PM, marco atzeri wrote: I am looking for the cause of the problem, so that I know how to prevent it. Or is the only answer to simply run rebaseall after installation? usually yes If that is the case, then why is it not part of the installation? currently, it is part of the installation /etc/postinstall/autorebase.bat.done $ cygcheck -f /etc/postinstall/autorebase.bat _autorebase-000444-1 Your attached cygcheck output claims something else. The rebase version should be updated to 4.4.1 as well. Don't think there is a mismatch: that output was Marco's, not mine. Unless I misunderstand . . . http://cygwin.com/ml/cygwin/2013-12/msg00085.html was your mail, so it's kind of hard to imagine that the attached cygcheck output was Marco's. Check the version numbers. It's _autorebase-000425-1 and rebase-4.4.0-1 in the cygcheck output. Okay, I see. It takes a cygwin expert to spot that one. No way I could tell that those two should match somehow. Ah, that is an interesting one: $ rebase -si rebase: failed to open rebase database /etc/rebase.db.i386: No such file or directory ...this here means that rebase never created the database, which in turn could point to rebase crashing or not having sufficient privileges on /etc. Something like that. What happens if you stop all Cygwin processes, including any service you installed, then start dash, make sure you're in /bin, and then call `./rebaseall -p'. Any helpful output? How about this; sure looks like something is wrong: ./rebaseall -p gzip: stdin: unexpected end of file Yes, something is wrong. Looks like you removed the /etc/setup directory or the contents of that dir. The content is created and maintained by the setup installer and rebaseall needs the information. Don't play games with the files under /etc unless you want to break your installation. It was never the idea to break the installation :) But, evidently, I did botch my bundle, so to speak. 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? Thanks for your (plural, including Marco) most excellent help. -- - Bartels -- 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
