Re: Rebaseall fails with error 6 on cygcrypt-0.dll
On Sun, Jul 4, 2010 at 1:07 AM, Larry Hall (Cygwin) wrote: > On 7/4/2010 1:01 AM, Alex Leigh wrote: >> >> Hi, >> >> I've been getting some STATUS_ACCESS_VIOLATION errors when running >> bash and some xwin programs, and after some searching I'm trying to >> run rebaseall to see if that would fix the problem. However, when >> running rebaseall from ash, I get the following error: "ReBaseImage >> (/usr/bin/cygcrypt-0.dll) failed with last error = 6". Searching >> around it seems error code 6 comes from the DLL being in use. However >> I made sure to close all running cygwin programs, and I went through >> each of my running programs to see if any of them loads that >> particular DLL, which none of them do. Could there be anything else >> that would cause rebaseall to fail on that particular DLL? Thanks. >> I've attached an output from cygcheck. > > Make sure you stopped all services and then reboot. I rebooted, then shut down all non-essential programs and services, and still get the same error. This is baffling...is there anything else that could cause this error? Alex -- 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
tar: symlinks unpacked to empty files
With tar-1.23-1 and recent snapshot: echo foo > foo ln -s $PWD/foo bar tar cf test.tar bar foo rm -f bar foo tar xf test.tar ls -l bar foo You will see that 'bar' is a 0-byte file with permissions instead of a symlink. The symlink reference need not be absolute; it also happens with relative links in different directories, but does not happen if I just "ln -s foo bar". Yaakov -- 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: Rebaseall fails with error 6 on cygcrypt-0.dll
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Alex Leigh wrote, On 4.7.2010 9:20: > On Sun, Jul 4, 2010 at 1:07 AM, Larry Hall (Cygwin) wrote: >> On 7/4/2010 1:01 AM, Alex Leigh wrote: >>> >>> Hi, >>> >>> I've been getting some STATUS_ACCESS_VIOLATION errors when running >>> bash and some xwin programs, and after some searching I'm trying to >>> run rebaseall to see if that would fix the problem. However, when >>> running rebaseall from ash, I get the following error: "ReBaseImage >>> (/usr/bin/cygcrypt-0.dll) failed with last error = 6". Searching >>> around it seems error code 6 comes from the DLL being in use. However >>> I made sure to close all running cygwin programs, and I went through >>> each of my running programs to see if any of them loads that >>> particular DLL, which none of them do. Could there be anything else >>> that would cause rebaseall to fail on that particular DLL? Thanks. >>> I've attached an output from cygcheck. >> >> Make sure you stopped all services and then reboot. > > I rebooted, then shut down all non-essential programs and services, > and still get the same error. This is baffling...is there anything > else that could cause this error? Download the Process Explorer and find out who is holding the file open. - -- VH -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREIAAYFAkwwYV8ACgkQr2CghdezFMl1DQCglBWOA0A0mJYaFDBOKK5MTn01 K+MAoNuLRRu3sQFPUQe+F6XFQT/cgfTU =krDb -END PGP SIGNATURE- -- 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
Building DLLs on C++ version code failed, but okay on C version code.
Hi there,
I wrote a file, hello.c. It has only one function: print a message like
"hello!".
# hello.c #
#include
void hello() { printf( "Hello.\n" ) ; }
$gcc -c hello.c
$gcc -shared -o hello.dll hello.o
I successufully built it as DLL, hello.dll.
Then, I rewrote it in c++.
# hello.cpp ###
#include
using namespace std ;
void hello() {cout << "Hello." << endl ;}
Then, I used the commands above to built DLL, but it failed. Why did it
fail?
--
View this message in context:
http://old.nabble.com/Building-DLLs-on-C%2B%2B-version-code-failed%2C-but-okay-on-C-version-code.-tp29068199p29068199.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
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: Building DLLs on C++ version code failed, but okay on C version code.
Forgot to attach error information.
hello.o:hello.cpp:(.text+0xd): undefined reference to
`std::basic_string, std::allocator
>::size() const'
hello.o:hello.cpp:(.text+0x60): undefined reference to
`std::basic_string, std::allocator
>::operator[](unsigned int) const'
hello.o:hello.cpp:(.text+0x9f): undefined reference to
`std::basic_string, std::allocator
>::operator[](unsigned int) const'
hello.o:hello.cpp:(.text+0xce): undefined reference to
`std::basic_string, std::allocator
>::operator[](unsigned int) const'
hello.o:hello.cpp:(.text+0x111): undefined reference to `std::cout'
hello.o:hello.cpp:(.text+0x116): undefined reference to
`std::basic_ostream >& std::operator<<
>(std::basic_ostream
>&, char const*)'
hello.o:hello.cpp:(.text+0x11e): undefined reference to
`std::basic_ostream >& std::endl >(std::basic_ostream
>&)'
hello.o:hello.cpp:(.text+0x126): undefined reference to
`std::basic_ostream
>::operator<<(std::basic_ostream >&
(*)(std::basic_ostream >&))'
hello.o:hello.cpp:(.text+0x149): undefined reference to
`std::ios_base::Init::Init()'
hello.o:hello.cpp:(.text+0x164): undefined reference to
`std::ios_base::Init::~Init()'
collect2: ld returned 1 exit status
ke...@ca wrote:
>
> Hi there,
>
> I wrote a file, hello.c. It has only one function: print a message like
> "hello!".
> # hello.c #
> #include
> void hello() { printf( "Hello.\n" ) ; }
>
> $gcc -c hello.c
> $gcc -shared -o hello.dll hello.o
>
> I successufully built it as DLL, hello.dll.
>
> Then, I rewrote it in c++.
> # hello.cpp ###
> #include
> using namespace std ;
> void hello() {cout << "Hello." << endl ;}
>
> Then, I used the commands above to built DLL, but it failed. Why did it
> fail?
>
>
--
View this message in context:
http://old.nabble.com/Building-DLLs-on-C%2B%2B-version-code-failed%2C-but-okay-on-C-version-code.-tp29068199p29068213.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
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: Building DLLs on C++ version code failed, but okay on C version code.
On 2010-07-04 12:27 PM, ke...@ca wrote:
Forgot to attach error information.
hello.o:hello.cpp:(.text+0xd): undefined reference to
`std::basic_string, std::allocator
::size() const'
hello.o:hello.cpp:(.text+0x60): undefined reference to
`std::basic_string, std::allocator
::operator[](unsigned int) const'
hello.o:hello.cpp:(.text+0x9f): undefined reference to
`std::basic_string, std::allocator
::operator[](unsigned int) const'
hello.o:hello.cpp:(.text+0xce): undefined reference to
`std::basic_string, std::allocator
::operator[](unsigned int) const'
hello.o:hello.cpp:(.text+0x111): undefined reference to `std::cout'
hello.o:hello.cpp:(.text+0x116): undefined reference to
`std::basic_ostream >& std::operator<<
>(std::basic_ostream
&, char const*)'
hello.o:hello.cpp:(.text+0x11e): undefined reference to
`std::basic_ostream >& std::endl >(std::basic_ostream
&)'
hello.o:hello.cpp:(.text+0x126): undefined reference to
`std::basic_ostream
::operator<<(std::basic_ostream >&
(*)(std::basic_ostream >&))'
hello.o:hello.cpp:(.text+0x149): undefined reference to
`std::ios_base::Init::Init()'
hello.o:hello.cpp:(.text+0x164): undefined reference to
`std::ios_base::Init::~Init()'
collect2: ld returned 1 exit status
ke...@ca wrote:
Hi there,
I wrote a file, hello.c. It has only one function: print a message like
"hello!".
# hello.c #
#include
void hello() { printf( "Hello.\n" ) ; }
$gcc -c hello.c
$gcc -shared -o hello.dll hello.o
I successufully built it as DLL, hello.dll.
Then, I rewrote it in c++.
# hello.cpp ###
#include
using namespace std ;
void hello() {cout<< "Hello."<< endl ;}
Then, I used the commands above to built DLL, but it failed. Why did it
fail?
Use g++ to compile and link c++ code
--
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: Building DLLs on C++ version code failed, but okay on C version code.
On 2010-07-04 10:24Z, ke...@ca wrote: > > $gcc -c hello.c > $gcc -shared -o hello.dll hello.o > > I successufully built it as DLL, hello.dll. Here, the C runtime library is automatically linked. > Then, I rewrote it in c++. [...] > Then, I used the commands above to built DLL, but it failed. Why did it > fail? Use 'g++' instead of 'gcc' for C++: g++ -c hello.cpp g++ -shared -o hello.dll hello.o Then the C++ standard library is automatically linked. -- 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
R: Building DLLs on C++ version code failed, but okay on C version code.
--- Dom 4/7/10, ke...@ca ha scritto:
>
> Hi there,
>
> I wrote a file, hello.c. It has only one function: print a
> message like
> "hello!".
> # hello.c #
> #include
> void hello() { printf( "Hello.\n" ) ; }
>
> $gcc -c hello.c
> $gcc -shared -o hello.dll hello.o
>
> I successufully built it as DLL, hello.dll.
>
> Then, I rewrote it in c++.
> # hello.cpp ###
> #include
> using namespace std ;
> void hello() {cout << "Hello." << endl ;}
>
> Then, I used the commands above to built DLL, but it
> failed. Why did it
> fail?
wrong compiler ?
For C++ you need a C++ compiler
$g++ -c hello.cpp
$g++ -shared -o hello.dll hello.o
Marco
PS: this is not a cygwin issue, it is a "very" basic one.
--
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
1.7.5: Error when invoking ghostscript (gs)
Hi, when I try to invoke gs from the Cygwin shell prompt, I get following error message: /usr/bin/gs.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory I have installed (reinstalled) the last version of ghostscript from the cygwin repository. $ cygcheck -c -v ghostscript Cygwin Package Information Last downloaded files to: C:\Users\XXX\Downloads Last downloaded files from: ftp://linux.rz.ruhr-uni-bochum.de/cygwin/ Package VersionStatus ghostscript 8.63-2 OK bye, Falk Cygwin Configuration Diagnostics Current System Time: Sun Jul 04 13:35:42 2010 Windows 7 Professional N Ver 6.1 Build 7600 Running under WOW64 on AMD64 Path: C:\Program Files\Java\jre6\bin C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\Program Files (x86)\MiKTeX 2.8\miktex\bin C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem C:\Windows\System32\WindowsPowerShell\v1.0\ C:\Program Files (x86)\Common Files\Teleca Shared C:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static C:\Users\XXX\AppData\Roaming\MiKTeX\2.8\miktex\bin\ Output from C:\cygwin\bin\id.exe UID: 1000(XXX) GID: 513(None) 513(None)545(Benutzer) SysDir: C:\Windows\system32 WinDir: C:\Windows USER = 'XXX' PWD = '/home/XXX' HOME = '/home/XXX' HOMEPATH = '\Users\XXX' MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man' APPDATA = 'C:\Users\XXX\AppData\Roaming' ProgramW6432 = 'C:\Program Files' HOSTNAME = 'COMPUTER' TERM = 'cygwin' PROCESSOR_IDENTIFIER = 'Intel64 Family 6 Model 30 Stepping 5, GenuineIntel' WINDIR = 'C:\Windows' PUBLIC = 'C:\Users\Public' OLDPWD = '/usr/bin' USERDOMAIN = 'COMPUTER' CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\ProgramData' DEFAULT_CA_NR = 'CA18' !:: = '::\' TEMP = '/cygdrive/c/Users/XXX/AppData/Local/Temp' COMMONPROGRAMFILES = 'C:\Program Files (x86)\Common Files' USERNAME = 'XXX' PROCESSOR_LEVEL = '6' ProgramFiles(x86) = 'C:\Program Files (x86)' PSModulePath = 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' PROCESSOR_ARCHITEW6432 = 'AMD64' LANG = 'C.UTF-8' USERPROFILE = 'C:\Users\XXX' PS1 = '\[\e]0;\w\a\]\n\[\e[32m\...@\h \[\e[33m\]\w\[\e[0m\]\n\$ ' LOGONSERVER = '\\COMPUTER' CommonProgramW6432 = 'C:\Program Files\Common Files' PROCESSOR_ARCHITECTURE = 'x86' LOCALAPPDATA = 'C:\Users\XXX\AppData\Local' !C: = 'C:\cygwin\bin' ProgramData = 'C:\ProgramData' SHLVL = '1' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC' HOMEDRIVE = 'C:' PROMPT = '$P$G' COMSPEC = 'C:\Windows\system32\cmd.exe' TMP = '/cygdrive/c/Users/XXX/AppData/Local/Temp' SYSTEMROOT = 'C:\Windows' PRINTER = '\\http://192.168.1.12:631\Laserjet2100' CVS_RSH = '/bin/ssh' PROCESSOR_REVISION = '1e05' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Program Files (x86)' NUMBER_OF_PROCESSORS = '4' SESSIONNAME = 'Console' COMPUTERNAME = 'COMPUTER' _ = '/usr/bin/cygcheck' HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygwin HKEY_CURRENT_USER\Software\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygwin\setup HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = '/cygdrive' cygdrive flags = 0x0022 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = 'C:\cygwin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = 'C:\cygwin/bin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = 'C:\cygwin/lib' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations (default) = '\??\C:\cygwin' HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup (default) = 'C:\cygwin' obcaseinsensitive set to 1 Cygwin installations found in the registry: System: Key: c5e39b7a9d22bafb Path: C:\cygwin c: hd NTFS102399Mb 83% CP CS UN PA FC System d: hd NTFS 39260Mb 50% CP CS UN PA FC Sicherung e: hd NTFS851366Mb 34% CP CS UN PA FC Daten f: cd CDFS52Mb 100%CS UN PONS h: fd FAT32 7647Mb 76% CPUN F1 C:\cygwin/ system binary,auto C:\cygwin\bin/usr/bin system binary,auto C:\cygwin\lib/usr/lib system binary,auto cygdrive prefix /cygdrive userbinary,auto Found: C:\cygwin\bin\awk Found: C:\cygwin\bin\awk -> C:\cygwin\bin\gawk.exe Found: C:\cygwin\bin\bash.exe Found: C:\cygwin\bin\bash.exe Found: C:\cygwin\bin\cat.e
Re: Rebaseall fails with error 6 on cygcrypt-0.dll
2010/7/4 Václav Haisman: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Alex Leigh wrote, On 4.7.2010 9:20: >> On Sun, Jul 4, 2010 at 1:07 AM, Larry Hall (Cygwin) wrote: >>> On 7/4/2010 1:01 AM, Alex Leigh wrote: Hi, I've been getting some STATUS_ACCESS_VIOLATION errors when running bash and some xwin programs, and after some searching I'm trying to run rebaseall to see if that would fix the problem. However, when running rebaseall from ash, I get the following error: "ReBaseImage (/usr/bin/cygcrypt-0.dll) failed with last error = 6". Searching around it seems error code 6 comes from the DLL being in use. However I made sure to close all running cygwin programs, and I went through each of my running programs to see if any of them loads that particular DLL, which none of them do. Could there be anything else that would cause rebaseall to fail on that particular DLL? Thanks. I've attached an output from cygcheck. >>> >>> Make sure you stopped all services and then reboot. >> >> I rebooted, then shut down all non-essential programs and services, >> and still get the same error. This is baffling...is there anything >> else that could cause this error? > Download the Process Explorer and find out who is holding the file open. Process Explorer is what I used and I made sure absolutely nothing is holding that file open. Alex -- 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: problems running "top" task monitor
Is there a way to investigate whether a unknown BLODA-app or something else causes the problem? Typically the process is just look at the security software that you have installed and try uninstalling one-by-one until the problem is resolved. Then you can reinstall all the other ones and report the problem to the vendor of the offending app. @ Corinna & Larry: Thanks for your hints and suggestions! I did what Larry wrote, there was only one piece of security software to uninstall. No luck. Fresh setup of cygwin. Still no luck. Reinstall new version of my av. Of course no luck... I can add to the problem-report that not only top doesn't work in 95% of invocations. On a random basis I get also fork()-errors or segfaults when launching one more xterm-window. Well, looks like I'm not hacker enough to solve it all on my own. So, to investigate the issue: is there some super-verbose or debug-mode to run cygwin/X/xterm/top to get further information what's going wrong? Probably everybody can easily imagine, that I'm not keen on rolling back the configured system to a plain unpatched W7 just to add one more item to BLODA. That's where my question regarding verbose/debug comes from. Furthermore I see from the list, lot's of people have issues with their cygwin/cygwinX installations on their w7 64bit boxes, often showing somehow similar symptoms. At the people who got it running without problems, segfaults, fork()-errors: What's the trick? Disabling UAC and Defender? Using an English language Windows? Turning on/off DEP, VT-x or whatever? Thanks in advance, Philipp -- 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: problems running "top" task monitor
On 7/4/2010 8:56 AM, P. Goldmann wrote: Is there a way to investigate whether a unknown BLODA-app or something else causes the problem? Typically the process is just look at the security software that you have installed and try uninstalling one-by-one until the problem is resolved. Then you can reinstall all the other ones and report the problem to the vendor of the offending app. @ Corinna& Larry: Thanks for your hints and suggestions! I did what Larry wrote, there was only one piece of security software to uninstall. No luck. Fresh setup of cygwin. Still no luck. Reinstall new version of my av. Of course no luck... I can add to the problem-report that not only top doesn't work in 95% of invocations. On a random basis I get also fork()-errors or segfaults when launching one more xterm-window. Well, looks like I'm not hacker enough to solve it all on my own. So, to investigate the issue: is there some super-verbose or debug-mode to run cygwin/X/xterm/top to get further information what's going wrong? Probably everybody can easily imagine, that I'm not keen on rolling back the configured system to a plain unpatched W7 just to add one more item to BLODA. That's where my question regarding verbose/debug comes from. Furthermore I see from the list, lot's of people have issues with their cygwin/cygwinX installations on their w7 64bit boxes, often showing somehow similar symptoms. At the people who got it running without problems, segfaults, fork()-errors: What's the trick? Disabling UAC and Defender? Using an English language Windows? Turning on/off DEP, VT-x or whatever? Have you tried rebaseall yet? Ken -- 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: Rebaseall fails with error 6 on cygcrypt-0.dll
Alex Leigh wrote: [snip] > I get the following error: "ReBaseImage > (/usr/bin/cygcrypt-0.dll) failed with last error = 6". Searching > around it seems error code 6 comes from the DLL being in use. Is that error code a Windows exit code? Then it means "The handle is invalid." (i.e. running 'net helpmsg 6'). If it is a code returned by a system function and reported by the program, then it means "No such device or address" (i.e. from /usr/include/sys/errno.h). Does it make sense? -- René Berber -- 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: tar: symlinks unpacked to empty files (tar security problem?)
On Sun, Jul 04, 2010 at 04:50:41AM -0500, Yaakov (Cygwin/X) wrote: >With tar-1.23-1 and recent snapshot: > >echo foo > foo >ln -s $PWD/foo bar >tar cf test.tar bar foo >rm -f bar foo >tar xf test.tar >ls -l bar foo > >You will see that 'bar' is a 0-byte file with permissions instead >of a symlink. The symlink reference need not be absolute; it also >happens with relative links in different directories, but does not >happen if I just "ln -s foo bar". That's because of the way that tar handles symlinks. If you have a reference to an absolute path, tar makes a zero-length regular file placeholder. Then when it is done extracting, tar is supposed to remove this file and create the real symlink. However, the test to make sure that it is ok to do this was broken by a recent DLL change. The inode returned the first time that the file was created was != the inode when the file is checked later. So tar thought that the zero-length file was modified and silently decided not to create the symlink. I've fixed the cygwin problem - it should be in the next snapshot. I think this silent behavior of tar is not too user friendly though. It seems like there is a pathological situation there where you'd end thinking that you'd extracted a symlink without getting the symlink. In fact, I think this is actually a security problem. Eric, am I missing something about tar's behavior here? 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: 1.7.5: Error when invoking ghostscript (gs)
On Sun, 2010-07-04 at 13:39 +0200, Falk Sticken wrote: > when I try to invoke gs from the Cygwin shell prompt, I get following > error message: > /usr/bin/gs.exe: error while loading shared libraries: ?: cannot open > shared object file: No such file or directory ldd /usr/bin/gs.exe will show you what your missing; in this case, I think you need to install libjpeg62. Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: problem updating to dash 0.5.6.1-2
On Fri, Jul 2, 2010 at 10:57 PM, Robert McDougall wrote: > Running `setup.exe`, to update dash from 0.5.6.1-1 to 0.5.6.1-2, > produces: > >> Unable to extract /usr/share/doc/dash/ChangeLog -- the file is in use. >> Please stop all Cygwin processes and select "Retry", or select >> "Continue" to go on anyway (you will need to reboot). > > No Cygwin window is open, and no process reported by Task Manager > appears relevant, except setup itself. So I see no Cygwin process to > stop. If curious, get Process Explorer from Sysinternals (now Microsoft). You can the search for in-use files. -- Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds -- 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: tar: symlinks unpacked to empty files (tar security problem?)
On Sun, 2010-07-04 at 13:17 -0400, Christopher Faylor wrote: > That's because of the way that tar handles symlinks. If you have a > reference to an absolute path, tar makes a zero-length regular file > placeholder. Then when it is done extracting, tar is supposed to remove > this file and create the real symlink. However, the test to make sure > that it is ok to do this was broken by a recent DLL change. The inode > returned the first time that the file was created was != the inode when > the file is checked later. So tar thought that the zero-length file was > modified and silently decided not to create the symlink. > > I've fixed the cygwin problem - it should be in the next snapshot. It appears to be working with 20100704 snapshot. Thanks for the quick response. Yaakov -- 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: 1.7.5: Error when invoking ghostscript (gs)
Yaakov (Cygwin/X) wrote: On Sun, 2010-07-04 at 13:39 +0200, Falk Sticken wrote: when I try to invoke gs from the Cygwin shell prompt, I get following error message: /usr/bin/gs.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory ldd /usr/bin/gs.exe will show you what your missing; in this case, I think you need to install libjpeg62. $ ldd /usr/bin/gs.exe ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x76fd) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x7514) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x76b2) cyggs-8.dll => /usr/bin/cyggs-8.dll (0x1000) cygX11-6.dll => /usr/bin/cygX11-6.dll (0x6c14) cyggcc_s-1.dll => /usr/bin/cyggcc_s-1.dll (0x67f0) cygwin1.dll => /usr/bin/cygwin1.dll (0x6100) ADVAPI32.DLL => /cygdrive/c/Windows/syswow64/ADVAPI32.DLL (0x7567) msvcrt.dll => /cygdrive/c/Windows/syswow64/msvcrt.dll (0x74d8) sechost.dll => /cygdrive/c/Windows/SysWOW64/sechost.dll (0x7692) RPCRT4.dll => /cygdrive/c/Windows/syswow64/RPCRT4.dll (0x7504) SspiCli.dll => /cygdrive/c/Windows/syswow64/SspiCli.dll (0x74b4) CRYPTBASE.dll => /cygdrive/c/Windows/syswow64/CRYPTBASE.dll (0x74b3) cygxcb-1.dll => /usr/bin/cygxcb-1.dll (0x6e7c) cygXau-6.dll => /usr/bin/cygXau-6.dll (0x6400) cygXdmcp-6.dll => /usr/bin/cygXdmcp-6.dll (0x6144) cygXt-6.dll => /usr/bin/cygXt-6.dll (0x689c) cygICE-6.dll => /usr/bin/cygICE-6.dll (0x6a34) cygSM-6.dll => /usr/bin/cygSM-6.dll (0x68e4) cyguuid-1.dll => /usr/bin/cyguuid-1.dll (0x64ec) cygcairo-2.dll => /usr/bin/cygcairo-2.dll (0x6dac) cygXrender-1.dll => /usr/bin/cygXrender-1.dll (0x6f60) cygfontconfig-1.dll => /usr/bin/cygfontconfig-1.dll (0x692c) cygexpat-1.dll => /usr/bin/cygexpat-1.dll (0x66ec) cygfreetype-6.dll => /usr/bin/cygfreetype-6.dll (0x6e08) cygz.dll => /usr/bin/cygz.dll (0x32) cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x674c) cygglitz-1.dll => /usr/bin/cygglitz-1.dll (0x6a18) cygpixman-1-0.dll => /usr/bin/cygpixman-1-0.dll (0x6fb4) cygpng12.dll => /usr/bin/cygpng12.dll (0x6f20) cygxcb-render-util-0.dll => /usr/bin/cygxcb-render-util-0.dll (0x6db8) cygxcb-render-0.dll => /usr/bin/cygxcb-render-0.dll (0x68c0) cygjasper-1.dll => /usr/bin/cygjasper-1.dll (0x6520) cygjpeg-7.dll => /usr/bin/cygjpeg-7.dll (0x66e0) Does not seem to be the problem. bye, Falk -- 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: 1.7.5: Error when invoking ghostscript (gs)
--- Dom 4/7/10, Falk Sticken ha scritto: > > On Sun, 2010-07-04 at 13:39 +0200, Falk Sticken > wrote: > >> when I try to invoke gs from the Cygwin shell > prompt, I get following error message: > >> /usr/bin/gs.exe: error while loading shared > libraries: ?: cannot open shared object file: No such file > or directory > > > > ldd /usr/bin/gs.exe will show you what your missing; > in this case, I > > think you need to install libjpeg62. > > $ ldd /usr/bin/gs.exe > ntdll.dll => > /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x76fd) > kernel32.dll => > /cygdrive/c/Windows/syswow64/kernel32.dll (0x7514) > KERNELBASE.dll => > /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x76b2) > cyggs-8.dll => > /usr/bin/cyggs-8.dll (0x1000) > cygX11-6.dll => > /usr/bin/cygX11-6.dll (0x6c14) > cyggcc_s-1.dll => > /usr/bin/cyggcc_s-1.dll (0x67f0) > cygwin1.dll => > /usr/bin/cygwin1.dll (0x6100) > ADVAPI32.DLL => > /cygdrive/c/Windows/syswow64/ADVAPI32.DLL (0x7567) > msvcrt.dll => > /cygdrive/c/Windows/syswow64/msvcrt.dll (0x74d8) > sechost.dll => > /cygdrive/c/Windows/SysWOW64/sechost.dll (0x7692) > RPCRT4.dll => > /cygdrive/c/Windows/syswow64/RPCRT4.dll (0x7504) > SspiCli.dll => > /cygdrive/c/Windows/syswow64/SspiCli.dll (0x74b4) > CRYPTBASE.dll => > /cygdrive/c/Windows/syswow64/CRYPTBASE.dll (0x74b3) > cygxcb-1.dll => > /usr/bin/cygxcb-1.dll (0x6e7c) > cygXau-6.dll => > /usr/bin/cygXau-6.dll (0x6400) > cygXdmcp-6.dll => > /usr/bin/cygXdmcp-6.dll (0x6144) > cygXt-6.dll => > /usr/bin/cygXt-6.dll (0x689c) > cygICE-6.dll => > /usr/bin/cygICE-6.dll (0x6a34) > cygSM-6.dll => > /usr/bin/cygSM-6.dll (0x68e4) > cyguuid-1.dll => > /usr/bin/cyguuid-1.dll (0x64ec) > cygcairo-2.dll => > /usr/bin/cygcairo-2.dll (0x6dac) > cygXrender-1.dll => > /usr/bin/cygXrender-1.dll (0x6f60) > cygfontconfig-1.dll => > /usr/bin/cygfontconfig-1.dll (0x692c) > cygexpat-1.dll => > /usr/bin/cygexpat-1.dll (0x66ec) > cygfreetype-6.dll => > /usr/bin/cygfreetype-6.dll (0x6e08) > cygz.dll => > /usr/bin/cygz.dll (0x32) > cygiconv-2.dll => > /usr/bin/cygiconv-2.dll (0x674c) > cygglitz-1.dll => > /usr/bin/cygglitz-1.dll (0x6a18) > cygpixman-1-0.dll => > /usr/bin/cygpixman-1-0.dll (0x6fb4) > cygpng12.dll => > /usr/bin/cygpng12.dll (0x6f20) > cygxcb-render-util-0.dll => > /usr/bin/cygxcb-render-util-0.dll (0x6db8) > cygxcb-render-0.dll => > /usr/bin/cygxcb-render-0.dll (0x68c0) > cygjasper-1.dll => > /usr/bin/cygjasper-1.dll (0x6520) > cygjpeg-7.dll => > /usr/bin/cygjpeg-7.dll (0x66e0) > > Does not seem to be the problem. > > bye, > Falk > > > -- > 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 > > ldd don't report the missing lib, eventually we should consider that a bug, while $ cygcheck gs.exe will report the missing C:\cygwin2\bin\cygjpeg-62.dll that comes from libjpeg62-6b-21 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: 1.7.5: Error when invoking ghostscript (gs)
Marco Atzeri wrote: --- Dom 4/7/10, Falk Sticken ha scritto: On Sun, 2010-07-04 at 13:39 +0200, Falk Sticken wrote: when I try to invoke gs from the Cygwin shell prompt, I get following error message: /usr/bin/gs.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory ldd /usr/bin/gs.exe will show you what your missing; in this case, I think you need to install libjpeg62. $ ldd /usr/bin/gs.exe ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x76fd) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x7514) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x76b2) cyggs-8.dll => /usr/bin/cyggs-8.dll (0x1000) cygX11-6.dll => /usr/bin/cygX11-6.dll (0x6c14) cyggcc_s-1.dll => /usr/bin/cyggcc_s-1.dll (0x67f0) cygwin1.dll => /usr/bin/cygwin1.dll (0x6100) ADVAPI32.DLL => /cygdrive/c/Windows/syswow64/ADVAPI32.DLL (0x7567) msvcrt.dll => /cygdrive/c/Windows/syswow64/msvcrt.dll (0x74d8) sechost.dll => /cygdrive/c/Windows/SysWOW64/sechost.dll (0x7692) RPCRT4.dll => /cygdrive/c/Windows/syswow64/RPCRT4.dll (0x7504) SspiCli.dll => /cygdrive/c/Windows/syswow64/SspiCli.dll (0x74b4) CRYPTBASE.dll => /cygdrive/c/Windows/syswow64/CRYPTBASE.dll (0x74b3) cygxcb-1.dll => /usr/bin/cygxcb-1.dll (0x6e7c) cygXau-6.dll => /usr/bin/cygXau-6.dll (0x6400) cygXdmcp-6.dll => /usr/bin/cygXdmcp-6.dll (0x6144) cygXt-6.dll => /usr/bin/cygXt-6.dll (0x689c) cygICE-6.dll => /usr/bin/cygICE-6.dll (0x6a34) cygSM-6.dll => /usr/bin/cygSM-6.dll (0x68e4) cyguuid-1.dll => /usr/bin/cyguuid-1.dll (0x64ec) cygcairo-2.dll => /usr/bin/cygcairo-2.dll (0x6dac) cygXrender-1.dll => /usr/bin/cygXrender-1.dll (0x6f60) cygfontconfig-1.dll => /usr/bin/cygfontconfig-1.dll (0x692c) cygexpat-1.dll => /usr/bin/cygexpat-1.dll (0x66ec) cygfreetype-6.dll => /usr/bin/cygfreetype-6.dll (0x6e08) cygz.dll => /usr/bin/cygz.dll (0x32) cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x674c) cygglitz-1.dll => /usr/bin/cygglitz-1.dll (0x6a18) cygpixman-1-0.dll => /usr/bin/cygpixman-1-0.dll (0x6fb4) cygpng12.dll => /usr/bin/cygpng12.dll (0x6f20) cygxcb-render-util-0.dll => /usr/bin/cygxcb-render-util-0.dll (0x6db8) cygxcb-render-0.dll => /usr/bin/cygxcb-render-0.dll (0x68c0) cygjasper-1.dll => /usr/bin/cygjasper-1.dll (0x6520) cygjpeg-7.dll => /usr/bin/cygjpeg-7.dll (0x66e0) Does not seem to be the problem. bye, Falk -- 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 ldd don't report the missing lib, eventually we should consider that a bug, while $ cygcheck gs.exe will report the missing C:\cygwin2\bin\cygjpeg-62.dll that comes from libjpeg62-6b-21 ok, installed libjpeg62-21 from the _obsolete branch. works. thx. bye, Falk -- 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: 1.7.5: Error when invoking ghostscript (gs)
On Sun, Jul 04, 2010 at 09:11:07PM +, Marco Atzeri wrote: >--- Dom 4/7/10, Falk Sticken ha scritto: > >> > On Sun, 2010-07-04 at 13:39 +0200, Falk Sticken >> wrote: >> >> when I try to invoke gs from the Cygwin shell >> prompt, I get following error message: >> >> /usr/bin/gs.exe: error while loading shared >> libraries: ?: cannot open shared object file: No such file >> or directory >> > >> > ldd /usr/bin/gs.exe will show you what your missing; >> in this case, I >> > think you need to install libjpeg62. >> >> $ ldd /usr/bin/gs.exe >> ? ? ? ? ntdll.dll => >> /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x76fd) >> ? ? ? ? kernel32.dll => >> /cygdrive/c/Windows/syswow64/kernel32.dll (0x7514) >> ? ? ? ? KERNELBASE.dll => >> /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x76b2) >> ? ? ? ? cyggs-8.dll => >> /usr/bin/cyggs-8.dll (0x1000) >> ? ? ? ? cygX11-6.dll => >> /usr/bin/cygX11-6.dll (0x6c14) >> ? ? ? ? cyggcc_s-1.dll => >> /usr/bin/cyggcc_s-1.dll (0x67f0) >> ? ? ? ? cygwin1.dll => >> /usr/bin/cygwin1.dll (0x6100) >> ? ? ? ? ADVAPI32.DLL => >> /cygdrive/c/Windows/syswow64/ADVAPI32.DLL (0x7567) >> ? ? ? ? msvcrt.dll => >> /cygdrive/c/Windows/syswow64/msvcrt.dll (0x74d8) >> ? ? ? ? sechost.dll => >> /cygdrive/c/Windows/SysWOW64/sechost.dll (0x7692) >> ? ? ? ? RPCRT4.dll => >> /cygdrive/c/Windows/syswow64/RPCRT4.dll (0x7504) >> ? ? ? ? SspiCli.dll => >> /cygdrive/c/Windows/syswow64/SspiCli.dll (0x74b4) >> ? ? ? ? CRYPTBASE.dll => >> /cygdrive/c/Windows/syswow64/CRYPTBASE.dll (0x74b3) >> ? ? ? ? cygxcb-1.dll => >> /usr/bin/cygxcb-1.dll (0x6e7c) >> ? ? ? ? cygXau-6.dll => >> /usr/bin/cygXau-6.dll (0x6400) >> ? ? ? ? cygXdmcp-6.dll => >> /usr/bin/cygXdmcp-6.dll (0x6144) >> ? ? ? ? cygXt-6.dll => >> /usr/bin/cygXt-6.dll (0x689c) >> ? ? ? ? cygICE-6.dll => >> /usr/bin/cygICE-6.dll (0x6a34) >> ? ? ? ? cygSM-6.dll => >> /usr/bin/cygSM-6.dll (0x68e4) >> ? ? ? ? cyguuid-1.dll => >> /usr/bin/cyguuid-1.dll (0x64ec) >> ? ? ? ? cygcairo-2.dll => >> /usr/bin/cygcairo-2.dll (0x6dac) >> ? ? ? ? cygXrender-1.dll => >> /usr/bin/cygXrender-1.dll (0x6f60) >> ? ? ? ? cygfontconfig-1.dll => >> /usr/bin/cygfontconfig-1.dll (0x692c) >> ? ? ? ? cygexpat-1.dll => >> /usr/bin/cygexpat-1.dll (0x66ec) >> ? ? ? ? cygfreetype-6.dll => >> /usr/bin/cygfreetype-6.dll (0x6e08) >> ? ? ? ? cygz.dll => >> /usr/bin/cygz.dll (0x32) >> ? ? ? ? cygiconv-2.dll => >> /usr/bin/cygiconv-2.dll (0x674c) >> ? ? ? ? cygglitz-1.dll => >> /usr/bin/cygglitz-1.dll (0x6a18) >> ? ? ? ? cygpixman-1-0.dll => >> /usr/bin/cygpixman-1-0.dll (0x6fb4) >> ? ? ? ? cygpng12.dll => >> /usr/bin/cygpng12.dll (0x6f20) >> ? ? ? ? cygxcb-render-util-0.dll => >> /usr/bin/cygxcb-render-util-0.dll (0x6db8) >> ? ? ? ? cygxcb-render-0.dll => >> /usr/bin/cygxcb-render-0.dll (0x68c0) >> ? ? ? ? cygjasper-1.dll => >> /usr/bin/cygjasper-1.dll (0x6520) >> ? ? ? ? cygjpeg-7.dll => >> /usr/bin/cygjpeg-7.dll (0x66e0) >> >> Does not seem to be the problem. >> >> bye, >> Falk >> >> >> -- >> 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 >> >> > >ldd don't report the missing lib, >eventually we should consider that a bug, >while > >$ cygcheck gs.exe > >will report the missing > >C:\cygwin2\bin\cygjpeg-62.dll > >that comes from libjpeg62-6b-21 There's no "eventually" to it. It is a bug if ldd isn't reporting missing dlls. 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: 1.7.5: Error when invoking ghostscript (gs)
On Sun, Jul 04, 2010 at 07:26:48PM -0400, Christopher Faylor wrote: >There's no "eventually" to it. It is a bug if ldd isn't reporting >missing dlls. The problem in this case is a missing nested dll. ldd doesn't yet have a mechanism to detect when a dll referenced by another dll is missing. I'm pondering the best way to deal with that now. 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: Incomplete downloads reported across several mirrors
On Wed, Jun 30, 2010 at 2:18 AM, Marco Atzeri <> wrote: > --- Mer 30/6/10, Jim Lawson ha scritto: > >> > I still have this kind of problem. Does anyone know is >> it should be so? >> > More info: >> > 1) gcc: C compiler upgrade helper - version 3.4.4.999 >> > 2) glib: Gnome C function library (1.2 sources) - >> version 1.2.10-10 >> > 3) libgnomecanvas2: GNOME canvas widget library >> (sources) - version 2.26.0-1 >> > >> > -- Forwarded message -- >> > From: Sergey Ivanov > com> >> > Date: 2010/1/30 >> > Subject: Intgrity fails? >> > To: cygwin@cygwin.com >> > >> > For about last month i still have troubles after >> "downloading without >> > installing" from ftp.kernel.org: >> > "partial view" newer empty - there are still 3 >> packages: >> > 1) gcc: C compiler upgrade helper >> > 2) glib: Gnome C function library (1.2 sources) - why >> actually sources >> > if only "bin" checked... >> > 3) libgnomecanvas2: GNOME canvas widget library >> (sources) >> > -- >> > King regards, >> > Sergey Ivanov >> >> >> >> > Date: Tue, 22 Jun 2010 19:44:47 -0400 >> > Message-ID: >> > Subject: Incomplete downloads reported across several >> mirrors >> > From: Gregg Levine > com> >> > >> > Hello!I've been trying to update this 1.7.5 release of >> Cygwin since 11AM >> > EDT, based on the multiple announcements of updated >> packages. Each >> > time I select a mirror and select those packages I >> want to update, the >> > process starts. >> > >> > It continues up to some particular point, and then I >> get the >> > incomplete download box, and the program wants me to >> try again. During >> > the first phase of this attempted update I was working >> in an area that >> > has had the rumors of a poorly configured proxy >> server, although the >> > information of how this server was configured was >> never told to me. >> > (Customer who has an IT department that sometimes >> resembles the >> > Anarchists Football League complete with clones of >> each of their >> > favorite stars.) >> > >> > Eventually after several repeated tries there, I >> waited until a few >> > minutes ago here, and decided to try again. This time >> it happened >> > again with the addition of the mirror based at the >> Open Software >> > repository at the Oregon State University. >> > - >> > Gregg C Levine gregg dot drwho8 at gmail dot com >> > "This signature fought the Time Wars, time and >> again." >> >> I suspect these problems may be due to a broken setup.ini >> file. The setup.ini file on mirrors.kernel.org (as of >> 6/29/10) seems to indicate that libgnomecanvas2 is a >> source-only package (it doesn't have an "install:" stanza), >> but other packages are dependent on it. setup.exe tries to >> install it to satisfy the dependencies but download_one() >> exits without success since the packagesource::sitestype >> iterator has nothing to iterate. >> >> Manually setting it to "Skip" in the "Gnome" category >> allows the process to complete, albeit with a warning >> message about the dependency. > > gcc and glib are empty package, > > from setup.ini > install: release/gcc/gcc-3.4.4-999.tar.bz2 46 > install: release/GNOME/glib/glib-1.2.10-10.tar.bz2 46 > > a 46 byte package is an empty bzipped tar file. > > They are there to allow the pull of other packages, > unfortunately setup forget to tick them and reinstall them > every time. > > libgnomecanvas2 is the source package of > libgnomecanvas2-devel > libgnomecanvas2_0 > > I see no package requiring it, all dependency are for > libgnomecanvas2_0 > > Marco > > Hello! It's been five days so far. And naturally there were some updates created since then. I decided to see if the problem was still present. (Whatever it was.) And it is gone. Completely. I was able to update my installation. - Gregg C Levine gregg.drw...@gmail.com "This signature fought the Time Wars, time and again." -- 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: Rebaseall fails with error 6 on cygcrypt-0.dll
On 7/4/2010 3:20 AM, Alex Leigh wrote: On Sun, Jul 4, 2010 at 1:07 AM, Larry Hall (Cygwin) wrote: On 7/4/2010 1:01 AM, Alex Leigh wrote: Hi, I've been getting some STATUS_ACCESS_VIOLATION errors when running bash and some xwin programs, and after some searching I'm trying to run rebaseall to see if that would fix the problem. However, when running rebaseall from ash, I get the following error: "ReBaseImage (/usr/bin/cygcrypt-0.dll) failed with last error = 6". Searching around it seems error code 6 comes from the DLL being in use. However I made sure to close all running cygwin programs, and I went through each of my running programs to see if any of them loads that particular DLL, which none of them do. Could there be anything else that would cause rebaseall to fail on that particular DLL? Thanks. I've attached an output from cygcheck. Make sure you stopped all services and then reboot. I rebooted, then shut down all non-essential programs and services, and still get the same error. This is baffling...is there anything else that could cause this error? Something has that DLL open/locked. I suppose it doesn't have to be Cygwin but I wouldn't know what that would be. Any rogue cygwin1.dlls on your system. To be sure you've excluded all things Cygwin from this install, do a 'cygrunsrv --list' followed by a 'cygrunsrv --stop ' where is any service you see listed by the previous command. -- 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? -- 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: Rebaseall fails with error 6 on cygcrypt-0.dll
On Sun, Jul 04, 2010 at 11:15:16PM -0400, Larry Hall (Cygwin) wrote: >On 7/4/2010 3:20 AM, Alex Leigh wrote: >> On Sun, Jul 4, 2010 at 1:07 AM, Larry Hall (Cygwin) wrote: >>> On 7/4/2010 1:01 AM, Alex Leigh wrote: I've been getting some STATUS_ACCESS_VIOLATION errors when running bash and some xwin programs, and after some searching I'm trying to run rebaseall to see if that would fix the problem. However, when running rebaseall from ash, I get the following error: "ReBaseImage (/usr/bin/cygcrypt-0.dll) failed with last error = 6". Searching around it seems error code 6 comes from the DLL being in use. However I made sure to close all running cygwin programs, and I went through each of my running programs to see if any of them loads that particular DLL, which none of them do. Could there be anything else that would cause rebaseall to fail on that particular DLL? Thanks. I've attached an output from cygcheck. >>> >>> Make sure you stopped all services and then reboot. >> >> I rebooted, then shut down all non-essential programs and services, >> and still get the same error. This is baffling...is there anything >> else that could cause this error? > >Something has that DLL open/locked. I suppose it doesn't have to be >Cygwin but I wouldn't know what that would be. Any rogue cygwin1.dlls >on your system. > >To be sure you've excluded all things Cygwin from this install, do a >'cygrunsrv --list' followed by a 'cygrunsrv --stop ' >where is any service you see listed by the previous >command. Actually, you might be able to get away with something like this from the DOS prompt. c: cd \cygwin\bin ren cygcrypt-0.dll cygcrypt-0.dll.hmm copy cygcrypt-0.dll.hmm cygcrypt-0.dll If you can do the rename but not the copy then reinstalling (via setup.exe's Reinstall option) cygcrypt-0.dll from the crypt package might work. 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: Rebaseall fails with error 6 on cygcrypt-0.dll
On Sun, Jul 4, 2010 at 11:15 PM, Larry Hall (Cygwin) wrote: > On 7/4/2010 3:20 AM, Alex Leigh wrote: >> >> On Sun, Jul 4, 2010 at 1:07 AM, Larry Hall (Cygwin) wrote: >>> >>> On 7/4/2010 1:01 AM, Alex Leigh wrote: Hi, I've been getting some STATUS_ACCESS_VIOLATION errors when running bash and some xwin programs, and after some searching I'm trying to run rebaseall to see if that would fix the problem. However, when running rebaseall from ash, I get the following error: "ReBaseImage (/usr/bin/cygcrypt-0.dll) failed with last error = 6". Searching around it seems error code 6 comes from the DLL being in use. However I made sure to close all running cygwin programs, and I went through each of my running programs to see if any of them loads that particular DLL, which none of them do. Could there be anything else that would cause rebaseall to fail on that particular DLL? Thanks. I've attached an output from cygcheck. >>> >>> Make sure you stopped all services and then reboot. >> >> I rebooted, then shut down all non-essential programs and services, >> and still get the same error. This is baffling...is there anything >> else that could cause this error? > > Something has that DLL open/locked. I suppose it doesn't have to be > Cygwin but I wouldn't know what that would be. Any rogue cygwin1.dlls > on your system. > > To be sure you've excluded all things Cygwin from this install, do a > 'cygrunsrv --list' followed by a 'cygrunsrv --stop ' > where is any service you see listed by the previous > command. Oops, I figured out why this was happening and it was rather silly on my part. I installed cygwin under the Administrator account and was trying to run rebaseall under a different account. I thought using the "run as administrator" option when opening ash would give it enough privileges but apparently it's not enough. Running ash under the actual Administrator account made the error go away and solved my status_access_violation problems. Thanks for the help everyone. Sincerely, Alex -- 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: R: Building DLLs on C++ version code failed, but okay on C version code.
thank you all. You all are right. I got the desired dlls. Now I know I was
misleaded by the statement that GCC is a collection of compilers and it
automatically use a compiler according to a programming language.
Marco atzeri-3 wrote:
>
> --- Dom 4/7/10, ke...@ca ha scritto:
>
>>
>> Hi there,
>>
>> I wrote a file, hello.c. It has only one function: print a
>> message like
>> "hello!".
>> # hello.c #
>> #include
>> void hello() { printf( "Hello.\n" ) ; }
>>
>> $gcc -c hello.c
>> $gcc -shared -o hello.dll hello.o
>>
>> I successufully built it as DLL, hello.dll.
>>
>> Then, I rewrote it in c++.
>> # hello.cpp ###
>> #include
>> using namespace std ;
>> void hello() {cout << "Hello." << endl ;}
>>
>> Then, I used the commands above to built DLL, but it
>> failed. Why did it
>> fail?
>
> wrong compiler ?
> For C++ you need a C++ compiler
>
> $g++ -c hello.cpp
> $g++ -shared -o hello.dll hello.o
>
> Marco
>
> PS: this is not a cygwin issue, it is a "very" basic one.
>
>
>
>
>
> --
> 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
>
>
>
--
View this message in context:
http://old.nabble.com/Building-DLLs-on-C%2B%2B-version-code-failed%2C-but-okay-on-C-version-code.-tp29068199p29073093.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
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: 1.7.5: Error when invoking ghostscript (gs)
--- Lun 5/7/10, Christopher Faylor ha scritto: > -0400, Christopher Faylor wrote: > >There's no "eventually" to it. It is a bug if ldd > isn't reporting > >missing dlls. > > The problem in this case is a missing nested dll. ldd > doesn't yet > have a mechanism to detect when a dll referenced by another > dll is > missing. I'm pondering the best way to deal with that > now. > > cgf > Hi Cristopher, just that you are verifying, please add this: if one of the direct referenced dll is missing, (I removed cygjpeg-62.dll) the outcome is not very helpful: $ ldd /usr/bin/cyggs-8.dll ntdll.dll => /cygdrive/c/WINDOWS/system32/ntdll.dll (0x7c90) kernel32.dll => /cygdrive/c/WINDOWS/system32/kernel32.dll (0x7c80) ??? => ??? (0x1000) ??? => ??? (0x6c14) ??? => ??? (0x67f0) ??? => ??? (0x6100) ??? => ??? (0x77dd) ??? => ??? (0x77e7) ??? => ??? (0x77fe) ??? => ??? (0x6e7c) ??? => ??? (0x6400) ??? => ??? (0x6144) ??? => ??? (0x689c) ??? => ??? (0x6a34) ??? => ??? (0x68e4) ??? => ??? (0x64ec) ??? => ??? (0x6dac) ??? => ??? (0x6f60) ??? => ??? (0x692c) ??? => ??? (0x66ec) ??? => ??? (0x6e08) ??? => ??? (0x3d) ??? => ??? (0x674c) ??? => ??? (0x6a18) ??? => ??? (0x6fb4) ??? => ??? (0x6f20) ??? => ??? (0x6db8) ??? => ??? (0x68c0) ??? => ??? (0x6520) ??? => ??? (0x66e0) 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
