Re: Can't install netCDF4
Edvardsen Kåre wrote: I need to install the netCDF4 package which is the Python/numpy interface to netCDF (see http://code.google.com/p/netcdf4-python/ ) I've tried to install version 0.9.4 and later, but they all give pretty much the same error message (attached). For me this looks like it is not ment to work under cygwin, but if anyone can help me out, I would really appreciate it. Reards, Kåre -- 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 I don't really use netCDF, but I read about a similar situation in here: http://code.google.com/p/netcdf4-python/issues/detail?id=2 So it seems you require the flag '--enable-netcdf-4' when calling the configure script for netcdf-4 or you haven't installed it at all. I would recommend reading the building documentation for netcdf4-python [1] and following the steps in detail. Specifically installing HDF5 and netcdf-4 before attempting to build netcdf4-python. Hope it helps, Tomas. [1]: http://netcdf4-python.googlecode.com/svn/trunk/README -- 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: Windows7 STATUS_ACCESS_VIOLATION and gcc/g++ linking problems
Yaakov (Cygwin/X) wrote: On Mon, 2011-04-11 at 13:44 -0400, Tomas Staig wrote: First I'll state that this is most probably not BLODA (unless some default program that comes with W7 provokes it), FWIW, Windows Defender is a default component of recent versions of Windows, including Win7, and is BLODA. Yaakov Thank you for your reply, Windows Defender was indeed running, although after stopping the service(from Windows Defender configuration) the same problem still happens. I tried restarting the system (with Windows Defender deactivated) just in case, but received the same outcome. I even tried stopping all the services the system allowed me with no better results. Is there anything else I could try? I'm quite confident now that this is not BLODA. Thanks 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
Windows7 STATUS_ACCESS_VIOLATION and gcc/g++ linking problems
Dear all, we have successfully ported an application framework (based on CORBA) to Windows using Cygwin last year. This porting works properly under Windows XP, but we ran into some problems when we tried to use it under Windows 7 (32-bits) not long ago. While compiling ACE/TAO (Initial parts of the compilation work ok), at some point it tries to execute the (compiled during the process) IDL compiler tao_idl.exe, which randomly (more often than not) ends up in an STATUS_ACCESS_VIOLATION message and, some of these times with an additional comment saying "preprocessor 'g++' returned with an error" which crashes the application. After this I ran tao_idl.exe by hand, receiving the same outcome. First I'll state that this is most probably not BLODA (unless some default program that comes with W7 provokes it), since I started with a fresh W7 installation made by myself on which I only installed Java JDK and Cygwin along with some of its packages. I've been looking around and found several supposed workaraounds to this issue: 1.- peflags --tsaware=true app_name.exe 2.- Disable DEP (Data Execution Prevention) 3.- rebaseall -v 4.- rebaseall -v -T list_of_compiled_dlls From this list only the last solution worked for me, but it is very uncomfortable to have to run this in the middle of a compilation process, since, first of all, we need to stop all the cygwin processes. For ACE/TAO for example this would mean to compile it by sections, maybe rebasing after each set of DLLs. This would require, for instance, a batch (.bat or other windows based) script and several bash scripts to be called by it. The thing is that later, when compiling Python (we use a specific version), a similar problem appeared (STATUS_ACCESS_VIOLATION messages that finish with a "fork: child -1 - died waiting for longjmp before initialization, retry 0, exit code 8800, errno 11", "error: Resource temporarily unavailable") when linking using gcc. Also I would think that the problem is gcc/g++ related due to both problems comming from it, but in this scenario I can't understand at the moment why the problem appears only when linking some libs and not others and why is it solved when using rebaseall providing the list of DLLs created during compilation time as opposed to doing this with the system DLLs only. Considering that the framework has a high number of modules(sets of libs and executables) I find a problem having to rebaseall after the compilation of each one. We use gcc/g++ version (GCC) 4.3.4 20090804 (release) 1 I have three questions that you might ignore if there is an answer for the underlying problem. 1.- For the external applications such as ACE/TAO or Python. What can we do to avoid running in the aformentioned problem without having to rebase in the middle of the compilation process? Looking at the linker flags of both ACE/TAO and Python, they already use the -Wl,--enable-auto-image-base linker flag. 2.- Is it enough for the DLLs if they are compiled using the -Wl,--enable-auto-image-base linker flag? From the outcome I see from ACE/TAO and Python it seems that it isn't enough. What else can we do? 3.- I know that WXP and W7 are very different, but is there something specific that causes these problem on W7 and not on WXP? I've been using Cygwin on WXP for some time and never had to rebase at all. I prefered to leave out the snippets of code and errors to keep the mail relatively short. If you want to have a look at any of them or want me to show the output of a specific command, please let me know. I appreciate your time reading this post and thank in advance any help or comment that you might share. Best regards, Tomás Staig. -- 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: libpq: problem with shared library
Tomáš Hajas wrote:
Hello,
I'm trying to use PostgreSQL C API under Cygwin, but libpq attempts load a very
strange shared library. On run-time it states:
"error while loading shared libraries: ?: cannot open shared object file: No
such file or directory"
and yes, name of the missing shared library is literally a question mark.
To reproduce the problem, all it takes is just to use the library:
#include
int main(int argc, char **argv)
{
PQconnectdb("dbname=test");
return 0;
}
Compiled with:
gcc -o pqtest pqtest.c /usr/lib/libpq.a
What could possibly cause this? Thanks in advace.
Best regards,
Tomas Hajas
--
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
Hi,
for some reason when this error message appears it has some problems
showing you which dll it isn't able to find. It happened to me with both
this question mark and with available dll files (while another dll was
the one really missing). What I did to see which dll was really missing
was to execute "strace program". This should pop up a windows message
with the real problem.
Hope this works for you.
Cheers,
Tomás.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: git stopped working with 1.7.1
survivant wrote: Does anyone one have an answer for this problem ? (I saw lot of threads in different forums.. but never an answer.) I'm trying to clone a repository from my computer to my computer. I,m using cygwin 1.7. I,m able to clone all my others projects without problems. This project is 900k.. and the others are better than that. I have no idea what going on. I deleted the project and repush it.. always the same problems. $ GIT_TRACE=1 git clone g...@localhost:SmallProject.git trace: built-in: git 'clone' 'g...@localhost:SmallProject.git' Cloning into SmallProject... trace: run_command: 'ssh' 'g...@localhost' 'git-upload-pack '\''SmallProject.git'\''' DEBUG:gitosis.serve.main:Got command "git-upload-pack 'SmallProject.git'" DEBUG:gitosis.access.haveAccess:Access check for 'jerabi' as 'writable' on 'SmallProject.git'... DEBUG:gitosis.access.haveAccess:Stripping .git suffix from 'SmallProject.git', new value 'SmallProject' DEBUG:gitosis.group.getMembership:found 'jerabi' in 'gitosis-admin' DEBUG:gitosis.group.getMembership:found 'jerabi' in 'dev_jerabi' DEBUG:gitosis.access.haveAccess:Access ok for 'jerabi' as 'writable' on 'SmallProject' DEBUG:gitosis.access.haveAccess:Using prefix 'repositories' for 'SmallProject' DEBUG:gitosis.serve.main:Serving git-upload-pack 'repositories/SmallProject.git' trace: run_command: 'index-pack' '--stdin' '-v' '--fix-thin' '--keep=fetch-pack 6900 on jerabi-THINK' trace: exec: 'git' 'index-pack' '--stdin' '-v' '--fix-thin' '--keep=fetch-pack 6900 on jerabi-THINK' remote: Counting objects: 344, done. trace: built-in: git 'index-pack' '--stdin' '-v' '--fix-thin' '--keep=fetch-pack 6900 on jerabi-THINK' remote: Compressing objects: 58% (134/230) remote: Compressing objects: 100% (230/230), done. fatal: The remote end hung up unexpectedly fatal: early EOF fatal: index-pack failed jer...@jerabi-think ~/workspaces/test $ $ git --version git version 1.7.2.3 Don't have a clue of why this happens (some people say it is because of openssh, that if you change it for putty's implementation it works well) but when that happens to me (while pulling, never tried with clone) I just try a couple of times until it succeeds: for (( i=0 ; i < 100 ; i++ )); do git pull; done works all the time for me... try something similar but with "git clone ..." of course. And well, I'm working with a 4+GB repository, so I'm really thankful that the clone worked right away. I know it's not the best solution, but if it works... it's good enough as a temporal workaround. Hope it works for you. Cheers, Tomas. -- 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: Linking shared libraries problem
Larry Hall (Cygwin) wrote: On 8/29/2010 7:08 PM, Tomás Staig wrote: Hi, I have been trying to port some software from Linux (Scientific Linux/RedHat) to windows using Cygwin. I have been able to port most of it with little changes but I encountered a problem when linking shared libraries. It seems that the chain of dependencies is not included when linking. Furthermore, ldd does not show the dependency libraries as in Linux. I have tried both using the import libraries (%.dll.a) and linking the dll files (%.dll) directly. I have arranged a small example program that reproduces this effect. Used Ubuntu 8.04 to and "CYGWIN_NT-5.1" version "1.7.6(0.230/5/3) 2010-08-16 16:06" on top of a 32-bits Windows XP Machine to test the above examples. As you can see, there is no reference to liby.dll. I could add the library (-ly) directly to the compiling line of main and it works, but the truth is that it would not be a good approach, since in the software I'm trying to port, there are several dependent modules, so the last ones would have an incredibly large list of dependencies. So, am I doing something wrong? Is there any way to add the dependency to be shown with ldd or any workaround(maybe a linker flag or something) to make the above example work? The Windows loader requires full resolution at link time. You need to list at least the import libraries for all dependencies if you want the link to succeed. Sorry, that's just the way Windows works. Thanks for your reply. I have found a workaround, however. Probably not the best thing to do in general, but for my case it is pretty useful: Makefile in Cygwin: all: g++ -c x.cpp g++ -c y.cpp g++ -shared -Wl,--output-def,liby.def -Wl,-out-implib=liby.dll.a -Wl,-export-all-symbols -Wl,-enable-auto-import -Wl,-whole-archive y.o -Wl,-no-whole-archive -o liby.dll g++ -shared -Wl,-out-implib=libx.dll.a -Wl,-export-all-symbols -Wl,-enable-auto-import -Wl,-whole-archive x.o liby.def -Wl,-no-whole-archive -L./ -ly -o libx.dll g++ -o main main.cpp -L./ -lx If anyone is going to use this, be aware that it might get you "multiple definition" problems. I still haven't checked how this behaves in the project I'm porting, but in this tiny example it works flawlessly. -- 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
