Re: [ITA] postgresql-9.2.2-1
On 1/15/2013 12:24 AM, marco atzeri wrote: On 1/14/2013 10:28 PM, Reini Urban wrote: On Mon, Jan 14, 2013 at 12:40 AM, marco atzeri wrote: /usr/lib/postgresql/dict_snowball.dll: fixing bad relocations Segmentation fault (core dumped) it seems that is not a contrib dll but a core function when we solve the rebase issue I will move to right package Not installing postgresql-contrib and skipping the dictionaries with $ mv /usr/share/postgresql/snowball_create.sql /usr/share/postgresql/snowball_create.sql_bk $ touch /usr/share/postgresql/snowball_create.sql $ psql Segmentation fault (core dumped) $ psql psql: could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket /tmp/.s.PGSQL.5432? re-uploading just in case I uploaded the wrong build. I am correctly able to initdb, createdb, run postgres , and connect with psql $ psql psql (9.2.2) Type help for help. marco=# quit marco-# ^C marco=# \q Regards Marco
Re: [ITA] postgresql-9.2.2-1
On Jan 15 00:24, marco atzeri wrote: On 1/14/2013 10:28 PM, Reini Urban wrote: On Mon, Jan 14, 2013 at 12:40 AM, marco atzeri wrote: wget -r -np -nH --cut-dirs=1 \ http://matzeri.altervista.org/cygwin-1.7/postgresql/index.html /etc/rc.d/init.d/postgresql needs an +x, added and the .exe in DAEMON is wrong ls -al /usr/sbin/postmaster /usr/sbin/postmaster - postgres.exe What you mean, that postmaster need an exe as extention ? It seems a fault of cygport post install that strip the .exe from the postmaster.exe link. If that's unclear, symlinks should *not* use the .exe extension. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
[rebase/patch] Support IMAGE_REL_BASED_DIR64 relocations
Hi Jason,
While looking into Marco's rebase problem I noticed that 64 bit support
in rebase was not complete. 64 bit uses IMAGE_REL_BASED_DIR64 relocation
entries, which were simply ignored since only the 32 bit variation
IMAGE_REL_BASED_HIGHLOW was supported at all. Also, it would have been
impossible to relocate 64 bit DLLs to addresses beyond the 4GB border
since the offset difference was kept as an int value. The below patch
fixes both oversight.
Ok to apply?
Thanks,
Corinna
* objectfile.h (LinkedObjectFile::performRelocation): Change type of
parameter to int64_t.
* rebaseimage.cc (ReBaseImage64): Change type of local variable
difference to int64_t.
* sections.cc (Relocations::check): Fix formatting.
(Relocations::relocate): Take difference parameter as int64_t. Call
cursec-debugprint rather than cursec-print and drop FIXME comment.
Handle Windows relocation info types IMAGE_REL_BASED_ABSOLUTE,
IMAGE_REL_BASED_HIGHLOW and IMAGE_REL_BASED_DIR64. Print error
output if another relocation type is found. Fix formatting.
* sections.h (Relocations::relocate): Change type of parameter to
int64_t.
Index: imagehelper/objectfile.h
===
RCS file:
/sourceware/projects/cygwin-apps-home/cvsfiles/rebase/imagehelper/objectfile.h,v
retrieving revision 1.6
diff -u -p -r1.6 objectfile.h
--- imagehelper/objectfile.h19 Mar 2012 17:57:49 - 1.6
+++ imagehelper/objectfile.h15 Jan 2013 12:35:45 -
@@ -125,7 +125,7 @@ class LinkedObjectFile : public ObjectFi
{
return relocs-fix();
}
-bool performRelocation(int difference)
+bool performRelocation(int64_t difference)
{
return relocs-relocate(difference);
}
Index: imagehelper/rebaseimage.cc
===
RCS file:
/sourceware/projects/cygwin-apps-home/cvsfiles/rebase/imagehelper/rebaseimage.cc,v
retrieving revision 1.6
diff -u -p -r1.6 rebaseimage.cc
--- imagehelper/rebaseimage.cc 30 Apr 2012 13:37:16 - 1.6
+++ imagehelper/rebaseimage.cc 15 Jan 2013 12:35:45 -
@@ -118,7 +118,7 @@ BOOL ReBaseImage64 (
ntheader32-FileHeader.TimeDateStamp = TimeStamp;
}
- int difference = *NewImageBase - *OldImageBase;
+ int64_t difference = *NewImageBase - *OldImageBase;
if (!dll.performRelocation(difference))
{
Index: imagehelper/sections.cc
===
RCS file:
/sourceware/projects/cygwin-apps-home/cvsfiles/rebase/imagehelper/sections.cc,v
retrieving revision 1.4
diff -u -p -r1.4 sections.cc
--- imagehelper/sections.cc 8 Jul 2011 07:18:55 - 1.4
+++ imagehelper/sections.cc 15 Jan 2013 12:35:45 -
@@ -302,14 +302,15 @@ bool Relocations::check(void)
int NumOfRelocs = (relocp-SizeOfBlock - sizeof(IMAGE_BASE_RELOCATION))
/ sizeof (WORD);
int va = relocp-VirtualAddress;
PWORD p = (PWORD)((uintptr_t)relocp + sizeof(IMAGE_BASE_RELOCATION));
- if (debug)
- std::cerr debug: blocksize= std::dec NumOfRelocs
std::endl;
+ if (debug)
+ std::cerr debug: blocksize= std::dec NumOfRelocs
std::endl;
cursec = sections-find(va);
- if (debug) {
- std::cerr debug: section= ;
- cursec-debugprint();
- }
+ if (debug)
+{
+ std::cerr debug: section= ;
+ cursec-debugprint();
+ }
if (!cursec)
{
if (debug)
@@ -319,11 +320,12 @@ bool Relocations::check(void)
errors++;
continue;
}
- for (int i = 0; i NumOfRelocs; i++,p++) {
- int location = (*p 0x0fff) + va;
- if (debug)
- std::cerr debug: location= 0x std::setw(8)
std::setfill('0') std::hex location std::endl;
- }
+ if (debug)
+ for (int i = 0; i NumOfRelocs; i++,p++)
+ {
+ int location = (*p 0x0fff) + va;
+ std::cerr debug: location= 0x std::setw(8)
std::setfill('0') std::hex location std::endl;
+ }
}
return errors == 0;
}
@@ -365,7 +367,7 @@ bool Relocations::fix(void)
}
-bool Relocations::relocate(int difference)
+bool Relocations::relocate(int64_t difference)
{
PIMAGE_BASE_RELOCATION relocp = relocs;
int WholeNumOfRelocs = 0;
@@ -386,8 +388,6 @@ bool Relocations::relocate(int differenc
}
WholeNumOfRelocs += NumOfRelocs;
- int adjust;
-
Section *cursec = sections-find(va);
if (!cursec)
{
@@ -398,29 +398,55 @@ bool Relocations::relocate(int differenc
return false;
}
else if (debug)
-// FIXME: this goes to cout but debug message should go to cerr
-cursec-print(currently relocated section);
- adjust =
Re: [rebase/patch] Support IMAGE_REL_BASED_DIR64 relocations
Corinna, On Tue, Jan 15, 2013 at 01:37:10PM +0100, Corinna Vinschen wrote: While looking into Marco's rebase problem I noticed that 64 bit support in rebase was not complete. 64 bit uses IMAGE_REL_BASED_DIR64 relocation entries, which were simply ignored since only the 32 bit variation IMAGE_REL_BASED_HIGHLOW was supported at all. Also, it would have been impossible to relocate 64 bit DLLs to addresses beyond the 4GB border since the offset difference was kept as an int value. The below patch fixes both oversight. Ok to apply? Yes. Let me know when you are ready and I will make a release. Thanks, Jason
rebase segfault
rebase is segfaulting on two dlls of new package postgresql-contrib-9.2.2-1 Full packages here http://matzeri.altervista.org/cygwin-1.7/postgresql/ Just the two dll's here: http://matzeri.altervista.org/works/rebase/ for i in *.dll; do echo $i ; rebase -O $i ; done dict_snowball.dll Segmentation fault (core dumped) ltree.dll Segmentation fault (core dumped) ltree.dll: file format pei-i386 ltree.dll architecture: i386, flags 0x010b: HAS_RELOC, EXEC_P, HAS_DEBUG, D_PAGED start address 0x4ef39370 Characteristics 0x212e executable line numbers stripped symbols stripped large address aware 32 bit words DLL Time/Date Tue Jan 15 09:32:57 2013 Magic 010b(PE32) MajorLinkerVersion 2 MinorLinkerVersion 22 SizeOfCode 8a00 SizeOfInitializedData ba00 SizeOfUninitializedData 0200 AddressOfEntryPoint 9370 BaseOfCode 1000 BaseOfData a000 ImageBase 4ef3 SectionAlignment1000 FileAlignment 0200 MajorOSystemVersion 4 MinorOSystemVersion 0 MajorImageVersion 1 MinorImageVersion 0 MajorSubsystemVersion 4 MinorSubsystemVersion 0 Win32Version SizeOfImage 0001 SizeOfHeaders 0400 CheckSum00012036 Subsystem 0003(Windows CUI) DllCharacteristics 8000 SizeOfStackReserve 0020 SizeOfStackCommit 1000 SizeOfHeapReserve 0010 SizeOfHeapCommit1000 LoaderFlags NumberOfRvaAndSizes 0010 Nothing obvious for me, but I am not a rebase expert... Regards 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: stat() and tilde prefix (was bad bash tab completion)
On Jan 14 16:37, Ryan Johnson wrote: On 14/01/2013 3:24 PM, Stephan Mueller wrote: Perhaps (as you may well have already considered): - replace the path prefix by the mount point first? (this may be naïve on my part, but it's not clear to me that .. early in a path should be able to influence which mount point is substituted) If I mount something at /foo/bar/baz, then /foo/bar/baz/../../blah definitely shouldn't end up inside baz. - test directory existence of the component preceding .. before collapsing (in the example above) b/.. to nothing. - trust that for a/b3/b2/b/../../../c, the existence test of a/b3/b2/b before collapsing b/.. to nothing implies existence of b2 and b3 so no further tests are needed for 'runs' of .. components with enough components before them Understood that this is still going to cause a slowdown because paths with .. are not uncommon, but it would reduce the number of additional existence checks from one-per-path-component to one-per-run-of-.., which means none in the case of paths without .. in them. The rest seems totally reasonable to me, FWIW. That's a chicken/egg-like situation. To be able to convert the POSIX path prefix (aka mount point) to the matching DOS path prefix, the path has to be normalized. But without being converted to a DOS path, you can't check path components. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: stat() and tilde prefix (was bad bash tab completion)
On Jan 14 23:14, Thomas Wolff wrote: Am 14.01.2013 11:00, schrieb Corinna Vinschen: ... The first step of converting a POSIX path to a Windows path is to normalize the path. . and .. components are simply dropped: a/b/./c - a\b\c a/b/../c - a\c which isn't correct already (even if everything exists) because if b is a symbolic link, b/.. is *not* . - (I think I came across this bug a few times already without really noticing it as a bug, having taken it as some spurious glitch...) Yes, that's a known downside. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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 segfault
On Jan 15 09:43, marco atzeri wrote: rebase is segfaulting on two dlls of new package postgresql-contrib-9.2.2-1 Full packages here http://matzeri.altervista.org/cygwin-1.7/postgresql/ Just the two dll's here: http://matzeri.altervista.org/works/rebase/ for i in *.dll; do echo $i ; rebase -O $i ; done dict_snowball.dll Segmentation fault (core dumped) ltree.dll Segmentation fault (core dumped) I don't know exactly what's going on here, but there's a common factor: $ objdump -h dict_snowball.dll dict_snowball.dll: file format pei-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 00016808 4ef01000 4ef01000 0400 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA 1 .data 00017180 4ef18000 4ef18000 00016e00 2**5 CONTENTS, ALLOC, LOAD, DATA 2 .bss 00f8 4ef3 4ef3 2**5 ALLOC 3 .edata0fe0 4ef31000 4ef31000 0002e000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .idata03e0 4ef32000 4ef32000 0002f000 2**2 CONTENTS, ALLOC, LOAD, DATA 5 .reloc765c 4ef33000 4ef33000 0002f400 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .gnu_deb 001c 4ef3b000 4ef3b000 00036c00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA $ objdump -h ltree.dll ltree.dll: file format pei-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 88a8 4ef31000 4ef31000 0400 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA 1 .data 0dc0 4ef3a000 4ef3a000 8e00 2**5 CONTENTS, ALLOC, LOAD, DATA 2 .bss 00f8 4ef3b000 4ef3b000 2**5 ALLOC 3 .edata0e3c 4ef3c000 4ef3c000 9c00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .idata05b8 4ef3d000 4ef3d000 ac00 2**2 CONTENTS, ALLOC, LOAD, DATA 5 .reloc0adc 4ef3e000 4ef3e000 b200 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .gnu_deb 0014 4ef3f000 4ef3f000 be00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA Both DLLs have a section .gnu_deb, whatever that one is good for. Rebase crashes both times when trying to relocate this .gnu_deb section. As you can see, the .gnu_deb section is pretty small, only 28 resp. 20 bytes. What happens is that the relocation information for the .gnu_deb section appears to be too big. In case of dict_snowball.dll, the reloc info covers 44 relocation entries. The segfault occurs as soon as one entry translates into a memory address which is beyond the committed area of the file memory map. Now, that's the *effect*. From this I can't say what the *cause* for this weird relocation info is. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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 segfault
On 1/15/2013 11:07 AM, Corinna Vinschen wrote: On Jan 15 09:43, marco atzeri wrote: rebase is segfaulting on two dlls of new package postgresql-contrib-9.2.2-1 Full packages here http://matzeri.altervista.org/cygwin-1.7/postgresql/ Just the two dll's here: http://matzeri.altervista.org/works/rebase/ for i in *.dll; do echo $i ; rebase -O $i ; done dict_snowball.dll Segmentation fault (core dumped) ltree.dll Segmentation fault (core dumped) I don't know exactly what's going on here, but there's a common factor: $ objdump -h dict_snowball.dll dict_snowball.dll: file format pei-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 00016808 4ef01000 4ef01000 0400 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA 1 .data 00017180 4ef18000 4ef18000 00016e00 2**5 CONTENTS, ALLOC, LOAD, DATA 2 .bss 00f8 4ef3 4ef3 2**5 ALLOC 3 .edata0fe0 4ef31000 4ef31000 0002e000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .idata03e0 4ef32000 4ef32000 0002f000 2**2 CONTENTS, ALLOC, LOAD, DATA 5 .reloc765c 4ef33000 4ef33000 0002f400 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .gnu_deb 001c 4ef3b000 4ef3b000 00036c00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA $ objdump -h ltree.dll ltree.dll: file format pei-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 88a8 4ef31000 4ef31000 0400 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA 1 .data 0dc0 4ef3a000 4ef3a000 8e00 2**5 CONTENTS, ALLOC, LOAD, DATA 2 .bss 00f8 4ef3b000 4ef3b000 2**5 ALLOC 3 .edata0e3c 4ef3c000 4ef3c000 9c00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .idata05b8 4ef3d000 4ef3d000 ac00 2**2 CONTENTS, ALLOC, LOAD, DATA 5 .reloc0adc 4ef3e000 4ef3e000 b200 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .gnu_deb 0014 4ef3f000 4ef3f000 be00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA Both DLLs have a section .gnu_deb, whatever that one is good for. Rebase crashes both times when trying to relocate this .gnu_deb section. As you can see, the .gnu_deb section is pretty small, only 28 resp. 20 bytes. What happens is that the relocation information for the .gnu_deb section appears to be too big. In case of dict_snowball.dll, the reloc info covers 44 relocation entries. The segfault occurs as soon as one entry translates into a memory address which is beyond the committed area of the file memory map. Now, that's the *effect*. From this I can't say what the *cause* for this weird relocation info is. Corinna It seems the result of the .dbg creation, that trunks wrongly the sections. I uploaded also the build and stripped versions: $ objdump.exe -h build/dict_snowball.dll build/dict_snowball.dll: file format pei-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 00016808 67ec1000 67ec1000 0400 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA 1 .data 00017180 67ed8000 67ed8000 00016e00 2**5 CONTENTS, ALLOC, LOAD, DATA 2 .bss 00f8 67ef 67ef 2**5 ALLOC 3 .edata0fe0 67ef1000 67ef1000 0002e000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .idata03e0 67ef2000 67ef2000 0002f000 2**2 CONTENTS, ALLOC, LOAD, DATA 5 .reloc765c 67ef3000 67ef3000 0002f400 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .debug_aranges 0560 67efb000 67efb000 00036c00 2**0 CONTENTS, READONLY, DEBUGGING 7 .debug_pubnames 1112 67efc000 67efc000 00037200 2**0 CONTENTS, READONLY, DEBUGGING 8 .debug_pubtypes 0f49 67efe000 67efe000 00038400 2**0 CONTENTS, READONLY, DEBUGGING 9 .debug_info 00048851 67eff000 67eff000 00039400 2**0 CONTENTS, READONLY, DEBUGGING 10 .debug_abbrev 50a3 67f48000 67f48000 00081e00 2**0 CONTENTS, READONLY, DEBUGGING 11 .debug_line 78a3 67f4e000 67f4e000 00087000 2**0 CONTENTS, READONLY, DEBUGGING 12 .debug_frame 2114 67f56000 67f56000 0008ea00 2**2 CONTENTS, READONLY, DEBUGGING 13 .debug_str0664 67f59000 67f59000 00090c00 2**0 CONTENTS, READONLY, DEBUGGING 14 .debug_loc000170a4 67f5a000 67f5a000 00091400 2**0
Re: rebase segfault
On Jan 15 11:36, marco atzeri wrote: On 1/15/2013 11:07 AM, Corinna Vinschen wrote: On Jan 15 09:43, marco atzeri wrote: rebase is segfaulting on two dlls of new package postgresql-contrib-9.2.2-1 Full packages here http://matzeri.altervista.org/cygwin-1.7/postgresql/ Just the two dll's here: http://matzeri.altervista.org/works/rebase/ for i in *.dll; do echo $i ; rebase -O $i ; done dict_snowball.dll Segmentation fault (core dumped) ltree.dll Segmentation fault (core dumped) I don't know exactly what's going on here, but there's a common factor: [...] Both DLLs have a section .gnu_deb, whatever that one is good for. Rebase crashes both times when trying to relocate this .gnu_deb section. As you can see, the .gnu_deb section is pretty small, only 28 resp. 20 bytes. What happens is that the relocation information for the .gnu_deb section appears to be too big. In case of dict_snowball.dll, the reloc info covers 44 relocation entries. The segfault occurs as soon as one entry translates into a memory address which is beyond the committed area of the file memory map. [...] It seems the result of the .dbg creation, that trunks wrongly the sections. [...] for what I can see a dll with debug symbols should have a .gnu_debuglink sections: Right. Something's scrambled. AFAIK, the .gnu_debuglink is not relocatable, it only contains a path. .gnu_deb appears to be a result of using only the fixed 8 bytes of the section name. Yaakov, do you have any idea what's going on here? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: stat() and tilde prefix (was bad bash tab completion)
Hi,
On 15 Jan 2013 03:13, Corinna Vinschen wrote:
It seems to me then that a patch to bash may be in order? I can see how
the bash check is the right thing to do. It doesn't want the special
tilde expansion to mask and disallow referencing of real tilde prefixed
paths. So the stat() check is the quick win to determine that.
From what I make of it, there needs to be a patch that, although can
work generically, adds checks only required for Cygwin. And therefore
is specific to the Cygwin package.
The check would be an extension of the file_exists() function, perhaps
called tilde_file_exists(), which determines if the tilde prefix forms
a directory component of the path (strchr('/')?). If it does not, the
file_exists() check is sufficient. If it does, then the check of if
that directory exists is logically and'ed to the result of
file_exists().
Does that sound about right?
A check like this might be a good idea. Ultimately I would be glad to
be able to come up with more correct code in Cygwin while not getting
slower, of course. But that's wishful thinking for now.
Bash, patched in the way I have described, seems to fix the tab
completion issue.
I will tidy up the work and publish the patch at some point soon. I may
have taken a naive approach, so review comments are welcome.
--
Regards,
Shaddy
--
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: unable to copy folder contents. showing error cannot stat. no such file directory
Thanks Andrey Repin. but if there is folder in the source path, it is not copying. Thanks Regards, Divakar On Thu, Dec 27, 2012 at 7:23 PM, Andrey Repin anrdae...@freemail.ru wrote: Greetings, Divakar K! can someone please help me to copy only the folder contents? copy /Y /Z D:\ostore_7.4_int_bld\package\ostore\* \\rdlserv\cdimage\ObjectStore\ostore\7.4.0\winnt_vc100\20121226\Win_32_VS_2010 Don't mix native windows environment and Cygwin tools without a good clue of what you're doing. in our script we used asterisk to copy the folder contents. but it is failing with the error. H:\cp -rf D:\ostore_7.4_int_bld\package\ostore\* \\rdlserv\cdimage\ObjectStore\ostore\7.4.0\winnt_vc100\20121226\Win_32_VS_2010 cp: cannot stat `D:\\ostore_7.4_int_bld\\package\\ostore\\*': No such file or directory if i omit asterisk then it is copying but with folder name which we dont need. H:\cp -rf D:\ostore_7.4_int_bld\package\ostore\ \\rdlserv\cdimage\ObjectStore\o store\7.4.0\winnt_vc100\20121226\Win_32_VS_2010 Thanks Regards, Divakar -- 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 -- WBR, Andrey Repin (anrdae...@freemail.ru) 27.12.2012, 17:51 Sorry for my terrible english... -- 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
How to rsh in windows using cygwin
Hi Folks, i dont know how to rsh from windows to windows? installed below packages which related to rsh. 1, rsh 2. rsh-server 3. tcp_wrapper 4. xinetd changed the disable value to no in the rsh conf file /etc/xinetd.d/rsh.conf. i think rshd services has to start. but i dont know how to start this and any other configuration need to be done? can someone please help me to do this? Thank you very much. Best Regards, Divakar -- 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: Another issue with CLANG
Yaakov wrote: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/llvm;a=blob;f=3.1-cygwin-includes.patch;h=1444765;hb=HEAD I think/hope you are going to send it to upstream... :-) Ciao, Angelo. -- 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: unable to copy folder contents. showing error cannot stat. no such file directory
Greetings, Divakar K! Thanks Andrey Repin. but if there is folder in the source path, it is not copying. cmd /C copy /? Thanks Regards, Divakar On Thu, Dec 27, 2012 at 7:23 PM, Andrey Repin anrdae...@freemail.ru wrote: Greetings, Divakar K! can someone please help me to copy only the folder contents? copy /Y /Z D:\ostore_7.4_int_bld\package\ostore\* \\rdlserv\cdimage\ObjectStore\ostore\7.4.0\winnt_vc100\20121226\Win_32_VS_2010 Don't mix native windows environment and Cygwin tools without a good clue of what you're doing. in our script we used asterisk to copy the folder contents. but it is failing with the error. H:\cp -rf D:\ostore_7.4_int_bld\package\ostore\* \\rdlserv\cdimage\ObjectStore\ostore\7.4.0\winnt_vc100\20121226\Win_32_VS_2010 cp: cannot stat `D:\\ostore_7.4_int_bld\\package\\ostore\\*': No such file or directory if i omit asterisk then it is copying but with folder name which we dont need. H:\cp -rf D:\ostore_7.4_int_bld\package\ostore\ \\rdlserv\cdimage\ObjectStore\o store\7.4.0\winnt_vc100\20121226\Win_32_VS_2010 Thanks Regards, Divakar -- 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 -- WBR, Andrey Repin (anrdae...@freemail.ru) 27.12.2012, 17:51 Sorry for my terrible english... -- 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 -- WBR, Andrey Repin (anrdae...@freemail.ru) 15.01.2013, 23:40 Sorry for my terrible english... -- 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: stat() and tilde prefix (was bad bash tab completion)
Greetings, Thomas Wolff! The first step of converting a POSIX path to a Windows path is to normalize the path. . and .. components are simply dropped: a/b/./c - a\b\c a/b/../c - a\c which isn't correct already (even if everything exists) because if b is a symbolic link, b/.. is *not* . - (I think I came across this bug a few times already without really noticing it as a bug, having taken it as some spurious glitch...) (Not sure whether this case is covered by further arguments in this thread) Only if it's a Cygwin symlink. Which I'm avoiding in my daily work, since NTFS now offers the same functionality. -- WBR, Andrey Repin (anrdae...@freemail.ru) 15.01.2013, 23:38 Sorry for my terrible english... -- 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: How to rsh in windows using cygwin
On 1/15/2013 7:42 AM, Divakar K wrote: Hi Folks, i dont know how to rsh from windows to windows? installed below packages which related to rsh. 1, rsh 2. rsh-server 3. tcp_wrapper 4. xinetd changed the disable value to no in the rsh conf file /etc/xinetd.d/rsh.conf. i think rshd services has to start. but i dont know how to start this and any other configuration need to be done? can someone please help me to do this? See the Cygwin documentation for this package in /usr/share/doc/Cygwin/xinetd.README. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: How to rsh in windows using cygwin
On 1/15/2013 11:54 AM, Larry Hall (Cygwin) wrote: On 1/15/2013 7:42 AM, Divakar K wrote: Hi Folks, i dont know how to rsh from windows to windows? installed below packages which related to rsh. 1, rsh 2. rsh-server 3. tcp_wrapper 4. xinetd changed the disable value to no in the rsh conf file /etc/xinetd.d/rsh.conf. i think rshd services has to start. but i dont know how to start this and any other configuration need to be done? can someone please help me to do this? See the Cygwin documentation for this package in /usr/share/doc/Cygwin/xinetd.README. I'm curious - is there a reason you don't want to use the more secure ssh? -- Andrew DeFaria http://defaria.com This space for rent -- 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: stat() and tilde prefix (was bad bash tab completion)
On 1/15/2013 2:39 PM, Andrey Repin wrote: Greetings, Thomas Wolff! The first step of converting a POSIX path to a Windows path is to normalize the path. . and .. components are simply dropped: a/b/./c - a\b\c a/b/../c - a\c which isn't correct already (even if everything exists) because if b is a symbolic link, b/.. is *not* . - (I think I came across this bug a few times already without really noticing it as a bug, having taken it as some spurious glitch...) (Not sure whether this case is covered by further arguments in this thread) Only if it's a Cygwin symlink. Which I'm avoiding in my daily work, since NTFS now offers the same functionality. Certainly if the native facilities work for you, you should use them. But I think there's been enough discussion in the past on this subject to acknowledge that the native functionality doesn't support all that Cygwin symlinks do. I'm making this (very) brief statement for the benefit of those that come across this in the archives. Anyone seeking clarification or more details should look in the archives for previous discussions on this subject. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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 segfault
On 1/15/2013 12:24 PM, Corinna Vinschen wrote:
On Jan 15 11:36, marco atzeri wrote:
On 1/15/2013 11:07 AM, Corinna Vinschen wrote:
On Jan 15 09:43, marco atzeri wrote:
rebase is segfaulting on two dlls of new package
postgresql-contrib-9.2.2-1
Full packages here
http://matzeri.altervista.org/cygwin-1.7/postgresql/
Just the two dll's here:
http://matzeri.altervista.org/works/rebase/
for i in *.dll; do echo $i ; rebase -O $i ; done
dict_snowball.dll
Segmentation fault (core dumped)
ltree.dll
Segmentation fault (core dumped)
I don't know exactly what's going on here, but there's a common
factor:
[...]
Both DLLs have a section .gnu_deb, whatever that one is good for.
Rebase crashes both times when trying to relocate this .gnu_deb section.
As you can see, the .gnu_deb section is pretty small, only 28 resp. 20
bytes. What happens is that the relocation information for the .gnu_deb
section appears to be too big. In case of dict_snowball.dll, the reloc
info covers 44 relocation entries. The segfault occurs as soon as one
entry translates into a memory address which is beyond the committed
area of the file memory map.
[...]
It seems the result of the .dbg creation, that trunks
wrongly the sections.
[...]
for what I can see a dll with debug symbols
should have a .gnu_debuglink sections:
Right. Something's scrambled. AFAIK, the .gnu_debuglink is not
relocatable, it only contains a path. .gnu_deb appears to be
a result of using only the fixed 8 bytes of the section name.
Yaakov, do you have any idea what's going on here?
it seems that objcopy is considering the
--long-section-names {enable|disable|keep}
as disable (or keeping an incorrect disable)
using in sequence on a stripped ltree.dll
$ objcopy -v --add-gnu-debuglink=ltree.dll.dbg ltree.dll
$ objcopy -v --long-section-names enable
--add-gnu-debuglink=ltree.dll.dbg ltree.dll
$ objdump -h ltree.dll
ltree.dll: file format pei-i386
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 88a8 6fc81000 6fc81000 0400 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
1 .data 0dc0 6fc8a000 6fc8a000 8e00 2**5
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00f8 6fc8b000 6fc8b000 2**5
ALLOC
3 .edata0e3c 6fc8c000 6fc8c000 9c00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .idata05b8 6fc8d000 6fc8d000 ac00 2**2
CONTENTS, ALLOC, LOAD, DATA
5 .reloc0adc 6fc8e000 6fc8e000 b200 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .gnu_deb 0014 6fc8f000 6fc8f000 be00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
7 .gnu_debuglink 0014 6fc9 6fc9 c000 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
I consider this a bug of objcopy:
--add-gnu-debuglink should imply --long-section-names enable
Corinna
Regards
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: Intermittent failures with ctrl-c (was: retrieving process exit codes)
On 01/02/2013 04:24 PM, Tom Honermann wrote: On 01/02/2013 03:48 PM, Christopher Faylor wrote: I managed to duplicate a hang by really stressing ctrl-c a loop. It uncovers some rather amazing Windows behavior which I have to think about. Apparently ExitThread can be called recursively within the thread that Windows creates to handle CTRL-C. I'm glad you could reproduce. Based on your description, this sounds like a separate issue and not a regression introduced by the workarounds you put in place for the ExitProcess / ExitThread race. Correct? I wonder if this is the same issue I'm experiencing though. I'm only pressing ctrl-c once and it sounds like you might be deliving a ctrl-c to the same process multiple times. That may not be relevant to the root cause however. I noticed that some changes were checked in related to signal handling and process termination recently, so I downloaded the most recent snapshot (20130114) and tested again. I was still able to produce hanging processes (including hangs of strace.exe) by hitting ctrl-c in a mintty window while Cygwin processes ran in an infinite loop inside of a .bat file. I was able to produce a hang ~1 out of 20 times. If you are still working on this, then I apologize for the noise. Otherwise, assuming you are still looking at this, if I can provide something further that would be helpful, please let me know. Tom. -- 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: deadlock with busy waiting on sigfe
On Tue, Jan 15, 2013 at 11:00:16AM +0900, jojelino wrote: Caused by executing following command and ctrl+c to interrupt in bash shell. sh -c cd /tmp/openjpeg/src/bin/jp2 /usr/bin/i686-pc-mingw32-gcc.exe -DOPJ_EXPORTS -ffast-math -O3 -DNDEBUG @CMakeFiles/opj_compress.dir/includes_C.rsp -o CMakeFiles/opj_compress.dir/convert.c.obj -c /tmp/openjpeg/src/bin/jp2/convert.c SleepEx is being spammed across threads. some thread got tls lock but didn't released it. how can i fix the problem? Sorry but there is no useful information here. How about providing some basic details like: 1) What version of Cygwin you're running. 2) A reproducer that doesn't involve downloading a large package and (apparently) running configure. ? You can also forgo the gdb backtraces. It is almost never useful to include those in a bug report. cgf -- 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: Intermittent failures with ctrl-c (was: retrieving process exit codes)
On Tue, Jan 15, 2013 at 05:16:57PM -0500, Tom Honermann wrote: I noticed that some changes were checked in related to signal handling and process termination recently, so I downloaded the most recent snapshot (20130114) and tested again. I was still able to produce hanging processes (including hangs of strace.exe) by hitting ctrl-c in a mintty window while Cygwin processes ran in an infinite loop inside of a .bat file. I was able to produce a hang ~1 out of 20 times. How does one run a .bat file inside mintty which handles CTRL-C? AFAIK, a CTRL-C will just cause the .bat file to exit when run under bash. cgf -- 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: deadlock with busy waiting on sigfe
On Tue, Jan 15, 2013 at 08:46:46PM -0500, Christopher Faylor wrote: On Tue, Jan 15, 2013 at 11:00:16AM +0900, jojelino wrote: Caused by executing following command and ctrl+c to interrupt in bash shell. sh -c cd /tmp/openjpeg/src/bin/jp2 /usr/bin/i686-pc-mingw32-gcc.exe -DOPJ_EXPORTS -ffast-math -O3 -DNDEBUG @CMakeFiles/opj_compress.dir/includes_C.rsp -o CMakeFiles/opj_compress.dir/convert.c.obj -c /tmp/openjpeg/src/bin/jp2/convert.c SleepEx is being spammed across threads. some thread got tls lock but didn't released it. how can i fix the problem? Sorry but there is no useful information here. How about providing some basic details like: 1) What version of Cygwin you're running. 2) A reproducer that doesn't involve downloading a large package and (apparently) running configure. ? You can also forgo the gdb backtraces. It is almost never useful to include those in a bug report. Sorry, the backtraces were actually useful because they show that you are apparently running cygwin-snapshot-20130107. Apparently you haven't been watching the discussion about this issue in the Cygwin list. The problem of a Cygwin process hanging after a single CTRL-C should be fixed in later snapshots although there is another reported CTRL-C issue. cgf -- 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 segfault
On 1/15/2013 11:03 PM, marco atzeri wrote:
On 1/15/2013 12:24 PM, Corinna Vinschen wrote:
On Jan 15 11:36, marco atzeri wrote:
On 1/15/2013 11:07 AM, Corinna Vinschen wrote:
On Jan 15 09:43, marco atzeri wrote:
rebase is segfaulting on two dlls of new package
postgresql-contrib-9.2.2-1
Full packages here
http://matzeri.altervista.org/cygwin-1.7/postgresql/
Just the two dll's here:
http://matzeri.altervista.org/works/rebase/
for i in *.dll; do echo $i ; rebase -O $i ; done
dict_snowball.dll
Segmentation fault (core dumped)
ltree.dll
Segmentation fault (core dumped)
I don't know exactly what's going on here, but there's a common
factor:
[...]
Both DLLs have a section .gnu_deb, whatever that one is good for.
Rebase crashes both times when trying to relocate this .gnu_deb
section.
As you can see, the .gnu_deb section is pretty small, only 28 resp. 20
bytes. What happens is that the relocation information for the
.gnu_deb
section appears to be too big. In case of dict_snowball.dll, the reloc
info covers 44 relocation entries. The segfault occurs as soon as one
entry translates into a memory address which is beyond the committed
area of the file memory map.
[...]
It seems the result of the .dbg creation, that trunks
wrongly the sections.
[...]
for what I can see a dll with debug symbols
should have a .gnu_debuglink sections:
Right. Something's scrambled. AFAIK, the .gnu_debuglink is not
relocatable, it only contains a path. .gnu_deb appears to be
a result of using only the fixed 8 bytes of the section name.
Yaakov, do you have any idea what's going on here?
it seems that objcopy is considering the
--long-section-names {enable|disable|keep}
as disable (or keeping an incorrect disable)
using in sequence on a stripped ltree.dll
it seems only a symptom, also using that, I have still one
rebase segfault more crazy than before.
(ltree.dll is fine now)
$ objdump -h dict_snowball.dll
dict_snowball.dll: file format pei-i386
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00016808 67ec1000 67ec1000 0400 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
1 .data 00017180 67ed8000 67ed8000 00016e00 2**5
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00f8 67ef 67ef 2**5
ALLOC
3 .edata0fe0 67ef1000 67ef1000 0002e000 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .idata03e0 67ef2000 67ef2000 0002f000 2**2
CONTENTS, ALLOC, LOAD, DATA
5 .reloc765c 67ef3000 67ef3000 0002f400 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .gnu_debuglink 001c 67efb000 67efb000 00036c00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
$ rebase -O dict_snowball.dll
Segmentation fault (core dumped)
It segfaults and a spurious character appears on the section:
$ objdump -h dict_snowball.dll
dict_snowball.dll: file format pei-i386
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00016808 4e971000 4e971000 0400 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
1 .data 00017180 4e988000 4e988000 00016e00 2**5
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00f8 4e9a 4e9a 2**5
ALLOC
3 .edata0fe0 4e9a1000 4e9a1000 0002e000 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .idata03e0 4e9a2000 4e9a2000 0002f000 2**2
CONTENTS, ALLOC, LOAD, DATA
5 .reloc765c 4e9a3000 4e9a3000 0002f400 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .gnu_debuglink▒ 001c 4e9ab000 4e9ab000 00036c00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
but the second time it works
$ rebase -O dict_snowball.dll
So it is now a rebase bug, a objcopy bug or both ?
all files here:
http://matzeri.altervista.org/works/rebase/
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
