X-win server will not start after upgrade
I've reinstalled cygwin and cygwin-X from setup ver 2.763, and now X-server won't start. Logfile attaced. Cheers, Kåre Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.11.4.0 OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (WoW64) Package: version 1.11.4-1 built 2012-01-29 XWin was started with the following command line: X :0 -multiwindow ddxProcessArgument - Initializing default screens winInitializeScreenDefaults - primary monitor w 1680 h 1050 winInitializeDefaultScreens - native DPI x 96 y 96 [ 15168.648] (II) xorg.conf is not supported [ 15168.648] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information [ 15168.648] LoadPreferences: /home/servicekonto/.XWinrc not found [ 15168.648] LoadPreferences: Loading /etc/X11/system.XWinrc [ 15168.648] LoadPreferences: Done parsing the configuration file... [ 15168.726] winDetectSupportedEngines - DirectDraw installed, allowing ShadowDD [ 15168.726] winDetectSupportedEngines - Windows NT, allowing PrimaryDD [ 15168.726] winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowDDNL [ 15168.726] winDetectSupportedEngines - Returning, supported engines 001f [ 15168.726] winSetEngine - Multi Window or Rootless = ShadowGDI [ 15168.726] winScreenInit - Using Windows display depth of 32 bits per pixel [ 15168.726] winAllocateFBShadowGDI - Creating DIB with width: 1680 height: 1050 depth: 32 [ 15168.726] winFinishScreenInitFB - Masks: 00ff ff00 00ff [ 15168.726] winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 [ 15168.726] winInitMultiWindowWM - Calling pthread_mutex_lock () [ 15168.726] winMultiWindowXMsgProc - Calling pthread_mutex_lock () [ 15168.726] Screen 0 added at virtual desktop coordinate (0,0). [ 15168.741] MIT-SHM extension disabled due to lack of kernel support [ 15168.741] XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel [ 15168.757] GL_VERSION: 1.1.0 [ 15168.757] GL_VENDOR: Microsoft Corporation [ 15168.757] GL_RENDERER:GDI Generic [ 15168.757] GL_EXTENSIONS: GL_WIN_swap_hint GL_EXT_bgra GL_EXT_paletted_texture [ 15168.757] wglwrap: Can't resolve wglGetExtensionsStringARB [ 15168.757] WGL_EXTENSIONS: (null)Segmentation fault at address 0x0 [ 15168.757] Fatal server error: [ 15168.757] Caught signal 11 (Segmentation fault). Server aborting [ 15168.757] [ 15168.757] Server terminated with error (1). Closing log file. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Can't install netCDF4
So, I followed the more detailed (but not so intuitive) descriptions for installing all hdf5, netcdf-4, and netCDF4, latest stable versions. Now, I bump into a different problem which seem to be related to libcurl (errorlog.txt attached). Can't quite figure out what's wrong, but I guess whatever libcurl-related packages I've installed that comes with cygwin is not enough? Regards, Kåre 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 HDF5_DIR environment variable not set, checking some standard locations .. checking /home/kare ... checking /usr/local ... HDF5 found in /usr/local NETCDF4_DIR environment variable not set, checking standard locations.. checking /home/kare ... checking /usr/local ... netCDF4 found in /usr/local running install running build running config_cc unifing config_cc, config, build_clib, build_ext, build commands --compiler options running config_fc unifing config_fc, config, build_clib, build_ext, build commands --fcompiler options running build_src build_src building py_modules sources building extension netCDF4 sources build_src: building npy-pkg config files running build_py running build_ext customize UnixCCompiler customize UnixCCompiler using build_ext building 'netCDF4' extension compiling C sources C compiler: gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes compile options: '-I/usr/local/include -I/usr/local/include -I/usr/lib/python2.6/site-packages/numpy/core/include -I/usr/include/python2.6 -c' gcc: netCDF4.c netCDF4.c: In function â__pyx_f_7netCDF4__find_cmptypeâ: netCDF4.c:34120:11: warning: â__pyx_v_xtypeâ may be used uninitialized in this function netCDF4.c: In function â__pyx_pf_7netCDF4_8Variable_10chunkingâ: netCDF4.c:24458:42: warning: â__pyx_v_ndimsâ may be used uninitialized in this function gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.7.9-i686-2.6/netCDF4.o -L/usr/local/lib -L/usr/local/lib -L/usr/lib/python2.6/config -Wl,-R/usr/local/lib -Wl,-R/usr/local/lib -lnetcdf -lhdf5_hl -lhdf5 -lz -lpython2.6 -o build/lib.cygwin-1.7.9-i686-2.6/netCDF4.dll /usr/local/lib/libnetcdf.a(liboc_la-ocinternal.o): In function `ocinternalinitialize': /home/kare/src/netcdf-4.1.3/oc/ocinternal.c:142: undefined reference to `_curl_version_info' /usr/local/lib/libnetcdf.a(liboc_la-http.o): In function `ocfetchhttpcode': /home/kare/src/netcdf-4.1.3/oc/http.c:27: undefined reference to `_curl_easy_getinfo' /usr/local/lib/libnetcdf.a(liboc_la-http.o): In function `ocfetchurl_file': /home/kare/src/netcdf-4.1.3/oc/http.c:41: undefined reference to `_curl_easy_setopt' /home/kare/src/netcdf-4.1.3/oc/http.c:46: undefined reference to `_curl_easy_setopt' /home/kare/src/netcdf-4.1.3/oc/http.c:79: undefined reference to `_curl_easy_strerror' /home/kare/src/netcdf-4.1.3/oc/http.c:51: undefined reference to `_curl_easy_setopt' /home/kare/src/netcdf-4.1.3/oc/http.c:56: undefined reference to `_curl_easy_setopt' /home/kare/src/netcdf-4.1.3/oc/http.c:60: undefined reference to `_curl_easy_perform' /home/kare/src/netcdf-4.1.3/oc/http.c:74: undefined reference to `_curl_easy_getinfo' /usr/local/lib/libnetcdf.a(liboc_la-http.o): In function `ocfetchurl': /home/kare/src/netcdf-4.1.3/oc/http.c:91: undefined reference to `_curl_easy_setopt' /home/kare/src/netcdf-4.1.3/oc/http.c:96: undefined reference to `_curl_easy_setopt' /home
Can't install netCDF4
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 HDF5_DIR environment variable not set, checking some standard locations .. checking /home/kare ... checking /usr/local ... checking /sw ... checking /opt ... checking /opt/local ... checking /usr ... HDF5 found in /usr NETCDF4_DIR environment variable not set, checking standard locations.. checking /home/kare ... checking /usr/local ... checking /sw ... checking /opt ... checking /opt/local ... checking /usr ... netCDF4 found in /usr running install running build running config_cc unifing config_cc, config, build_clib, build_ext, build commands --compiler options running config_fc unifing config_fc, config, build_clib, build_ext, build commands --fcompiler options running build_src build_src building py_modules sources building extension netCDF4 sources build_src: building npy-pkg config files running build_py running build_ext customize UnixCCompiler customize UnixCCompiler using build_ext building 'netCDF4' extension compiling C sources C compiler: gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes compile options: '-I/usr/include -I/usr/include -I/usr/lib/python2.6/site-packages/numpy/core/include -I/usr/include/python2.6 -c' gcc: netCDF4.c netCDF4.c: In function â__pyx_pf_7netCDF4_6getlibversionâ: netCDF4.c:2513:21: warning: assignment discards qualifiers from pointer target type netCDF4.c: In function â__pyx_f_7netCDF4__get_att_namesâ: netCDF4.c:8696:15: warning: assignment discards qualifiers from pointer target type netCDF4.c:8764:17: warning: assignment discards qualifiers from pointer target type netCDF4.c: In function â__pyx_f_7netCDF4__get_attâ: netCDF4.c:8928:15: warning: assignment discards qualifiers from pointer target type netCDF4.c:8956:10: error: âNC_STRINGâ undeclared (first use in this function) netCDF4.c:8956:10: note: each undeclared identifier is reported only once for each function it appears in netCDF4.c:9019:17: warning: assignment discards qualifiers from pointer target type netCDF4.c:9334:17: warning: assignment discards qualifiers from pointer target type netCDF4.c: In function â__pyx_f_7netCDF4__get_formatâ: netCDF4.c:9687:15: warning: assignment discards qualifiers from pointer target type netCDF4.c: In function â__pyx_f_7netCDF4__set_attâ: netCDF4.c:10221:17: warning: assignment discards qualifiers from pointer target type netCDF4.c:10404:17: warning: assignment discards qualifiers from pointer target type netCDF4.c: In function â__pyx_f_7netCDF4__get_typesâ: netCDF4.c:10494:3: warning: implicit declaration of function ânc_inq_typeidsâ netCDF4.c:10513:15: warning: assignment discards qualifiers from pointer target type netCDF4.c:10612:7: warning: implicit declaration of function ânc_inq_user_typeâ netCDF4.c:10631:19: warning: assignment discards qualifiers from pointer target type netCDF4.c:10666:14: error: âNC_COMPOUNDâ undeclared (first use in this function) netCDF4.c:10802:14: error: âNC_VLENâ undeclared (first use in this function) netCDF4.c: In function â__pyx_f_7netCDF4__get_dimsâ: netCDF4.c:11034:15: warning: assignment discards qualifiers from pointer target type netCDF4.c:11106:7: warning: implicit declaration of function ânc_inq_dimidsâ netCDF4.c:11125:19: warning: assignment discards qualifiers from pointer target type netCDF4.c:11209:19: warning: assignment discards qualifiers from pointer target type netCDF4.c: In function â__pyx_f_7netCDF4__get_grpsâ: netCDF4.c:11353:3: warning: implicit declaration of function ânc_inq_grpsâ netCDF4.c:11372:15: warning: assignment discards qualifiers from pointer target type netCDF4.c:11456:17: warning: assignment discards qualifiers from pointer target type netCDF4.c:11492:7: warning: implicit declaration of function ânc_inq_grpnameâ netCDF4.c:11511:19: warning: assignment discards qualifiers from pointer target type netCDF4.c: In function â__pyx_f_7netCDF4__get_varsâ: netCDF4.c:11707:15: warning: assignment discards qualifiers from pointer target type netCDF4.c:11788:7: warning: implicit declaration of function ânc_inq_varidsâ netCDF4.c:11807:19: warning: assignment discards qualifiers from pointer target type netCDF4.c:11900:19: warning: assignment discards qualifiers from pointer target type netCDF4.c:11963:19: warning: assignment discards qualifiers from pointer target type netCDF4.c:12012:19: warning: assignment discards qualifiers from pointer target type netCDF4.c:12093:41: error: âNC_STRINGâ undeclared (first use in this function) netCDF4.c:12147:20: error: âNC_COMPOUNDâ undeclared (first use in this
Re: [SOLVED] Re: What updates done after October 3 may affect gfortran built binaries?
I helped Edvardsen to track this down off-list. It turns out that FLEXPART is one of those huge number-crunching Fortran programs that's just jam-packed with ginormous multi-dimensional arrays. The final linked executable had 3.38 GB of .bss space! So, it's not too surprising that it didn't load on 32-bit Windows; and it's not, as I was worrying, any explicit bug in the compiler or binutils (although it may be arguable that ld could be helpful if it issued some kind of warning in these circumstances). Out of curiosity, how then was the OP ever able to make *any* version run? Ryan I'm not sure of the exact pre-required settings I had when I compiled FLEXPART to have a successful executable, but there seem to be various default parameter settings in some of the FLEXPART include files that will lead to some ginormous multi dimensional arrays. I was pretty sure I did the exact same procedure when I compiled FLEXPART later and got the non working executable, but if the .bss space was too large, I must have done something else before. It's just that I can't possibly think of anything I did different. However, I'm determined to locate the problem, to advice the FLEXPART developers. I don't want others to go through something similar. Kåre
Re: [SOLVED] Re: What updates done after October 3 may affect gfortran built binaries?
FLEXPART is one of those huge number-crunching Fortran programs that's just jam-packed with ginormous multi-dimensional arrays. The final linked executable had 3.38 GB of .bss space! Out of curiosity, how then was the OP ever able to make *any* version run? Not clear yet but probably owing to changes in one or more of the array dimensions in the upstream source that he didn't notice taking place. cheers, DaveK I managed to track down one critical array specification which I sat smaller before compiling. The 64-bit version use the same initialisation file as the 32-bit, so an array size of 22E+06 elements instead of 6E+06 was used. The SizeOfUninitializedData is now 5eeba800 (1.6 GB) and everything works beautiful :) I would never had thought of this without your help! Thank you very much! Cheers, Kåre
Re: What updates done after October 3 may affect gfortran built binaries?
In order to replicate my build you need to install latest version of the grib_api library (http://www.ecmwf.int/products/data/software/download/grib_api.html) and istall it with jasper What is jasper? Wikipedia lists four entirely different open source projects by that name! Also, how big is your build directory? If of a manageable size, please zip/tar it up and send me a copy off-list; if it's huge, please just send me a copy of the broken executable (also off-list). cheers, DaveK Sorry for my lack of info... jasper is a JPEG 2000 library. It's shipped with cygwin so for installing grib_api, you just have to specify ./configure prefix=some-preferred-install-dir --with-jasper if you have chosen the jasper package in your cygwin setup. You will probably experience a hang on Checking for ANSI C header files... during ./configure, like I referred to in an earlier thread. Reinstalling gcc 4.3.4 will solve that for you. Right now, I'm trying to rebuild my problem code with both earlier versions of binutils and gcc, like when I could build a working binary. If it fails, I will send you off-list copies and proper instructions for a successful build that will give you (probably) a broken binary. Thanx for your patience, Kåre
Re: What updates done after October 3 may affect gfortran built binaries?
Thanx a lot, Marco for takng time! In order to replicate my build you need to install latest version of the grib_api library (http://www.ecmwf.int/products/data/software/download/grib_api.html) and istall it with jasper tar xvfz grib_api-1.9.9.tar.gz ./configure [--with-jasper=jasper path] make make install You then have to edit the makefile.ecmwf_gfortran_32 to have the right lib and include path's set for gfortran to find jasper and grib_api. The path's found in makefile.ecmwf_gfortran_32 are just showing where the programmers installed those lib's before distributing the FLEXPART software. If you get a successful build, it will still prompt an error since you will still miss some expected settings, but you will clearly see whether this is a bad binary or not. I will definitely try reinstalling an older version of binutils and give it a try. Thanx again for the advice. Regards, KÃre I forgot to say that the file includepar in the FLEXPART folder need to be edited to look like this in the section: ** C Maximum dimensions of the input mother grids ** integer nxmax,nymax,nuvzmax,nwzmax,nzmax,nxshift parameter(nxmax=361,nymax=181,nuvzmax=92,nwzmax=92,nzmax=92) c parameter(nxmax=361,nymax=181,nuvzmax=61,nwzmax=61,nzmax=61) c parameter(nxmax=721,nymax=361,nuvzmax=27,nwzmax=27,nzmax=27) parameter(nxshift=359) ! for ECMWF c parameter(nxshift=0)! for GFS integer nconvlevmax,na parameter (nconvlevmax = nuvzmax-1) parameter (na = nconvlevmax+1) otherwise you will get a crash with some error messages during the make procedure. Thanx, Kåre
What updates done after October 3 may affect gfortran built binaries?
This is again related to the failure of execution of a gfortran built binary (cannot execute binary, see thread http://cygwin.com/ml/cygwin/2011-11/msg00034.html ) In short, the main problem is that I can't build a successful binary from the FLEXPART fortran code (just google FLEXPART nilu if you are curious of what FLEXPART is) on a cygwin installation I did just over a week ago, but it builds and run without problem on an installation from October 3. I get no differences in warnings from the bad build compared to the good one, so I really don't know what to look for. So far I have come to the conclusion that this must be related to one or several changes in the cygwin distribution done after October 3. Through try and failure testing I found that this is not affected by gfortran/gcc as both gcc 4.3.4 and gcc 4.5.3 works. The latter hangs on '$EGREP' calls in the 'grib_api' (required library) configure script, but the workaround of changing to 'egrep' works fine. I have posted the output from strace, objdump and cygcheck for some of you to look at in the former thread, but it seem like this is far from a straight forward problem. I can see from the [ANNOUNCEMENT] posts that a few things in this cygwin distro have been updated since October 3 and I kindly ask if someone have an idea of what updates since then may cause a badly gfortran built binary if it has nothing to do with gcc alone? I will now start going through the updates and change back to versions yielding October 3 if possible. I think this is important since cygwin will give the opportunity to run and develop FLEXPART on Windows machines the way linux-users are used to. In addition, I also see a potential problem of other fortran software that people want to run under cygwin. Regards, Kåre
Re: What updates done after October 3 may affect gfortran built binaries?
[...] I will now start going through the updates and change back to versions yielding October 3 if possible. I think this is important since cygwin will give the opportunity to run and develop FLEXPART on Windows machines the way linux-users are used to. In addition, I also see a potential problem of other fortran software that people want to run under cygwin. Regards, KÃre my guess binutils http://cygwin.com/ml/cygwin-announce/2011-10/msg00028.html or some BLODA. I downloaded the http://zardoz.nilu.no/~flexpart/flexpart/flexpart_82-3.tar.gz but it is not clear to me how to replicate your build. make -f makefile.gfs_gfortran_32 fails here: --- $ make -f makefile.gfs_gfortran_32 gfortran -O2 -m32 -fconvert=little-endian -frecord-marker=4 -I/nilu2/home/flexpart/lib/gfortran/include -c -o writeheader.o writeheader.f includecom:685.22: Included at writeheader.f:50: common /globalr/ ! REAL 1 Error: The equivalence set for 'pplev' cause an invalid extension to COMMON 'globalr' at (1) .. --- Regards Marco Thanx a lot, Marco for takng time! In order to replicate my build you need to install latest version of the grib_api library (http://www.ecmwf.int/products/data/software/download/grib_api.html) and istall it with jasper tar xvfz grib_api-1.9.9.tar.gz ./configure [--with-jasper=jasper path] make make install You then have to edit the makefile.ecmwf_gfortran_32 to have the right lib and include path's set for gfortran to find jasper and grib_api. The path's found in makefile.ecmwf_gfortran_32 are just showing where the programmers installed those lib's before distributing the FLEXPART software. If you get a successful build, it will still prompt an error since you will still miss some expected settings, but you will clearly see whether this is a bad binary or not. I will definitely try reinstalling an older version of binutils and give it a try. Thanx again for the advice. Regards, Kåre
Re: Problem with execution of binary file
Mark Geisert (that's me) wrote: I haven't yet diff'd the two cygchecks you sent but maybe that'll lead somewhere. I've now done that. The 'good' cygcheck shows many more packages installed than the 'bad' cygcheck. But the only package version differences I found were for bzr, find and mercurial; the 'good' cygcheck paradoxically shows earlier versions for those three packages. Hard to see how those package differences could matter though. About the only thing I can think of, and it's a crazy idea, is that the 'good' environment, with more packages installed, is somehow supplying something that's emulated badly in the 'bad' environment. Figuring out if that's the case would involve building your executable with every possible verbose switch turned on so you can identify exactly where every item going into the executable is coming from. Repeated in both 'good' and 'bad' environments. Or, you could take heart that you've got a good build you can work with now and just run with that. Maybe somebody else has another approach to try. HTH, ..mark Yes, the 'good' installation was done Oct. 3 with many more packages than the bad one. Just a week ago I wanted to install cygwin and run my software on other machines, and then I ran into this problem. It's not a paradox that the good installation has earlier package versions since it was installed a month earlier than the bad one :) So, my problem is now to isolate what has changed since then, which is affecting the build of my fortran binary. There is one thing I remember that is different now when I install a required library (grib-api, see post http://cygwin.com/ml/cygwin/2011-10/msg00037.html) I did not experience this hang back one month ago, but I've upgraded gcc since then, and I wonder if the grib_api, and then my software, is affected by this. I will try to rebuild everything with gcc 4.3.4 too se if it helps, and report the result to the list. Cheers
Re: Problem with execution of binary file
On 11/3/2011 4:56 PM, Eliot Moss wrote: Ok, so here's one thing about bash: to get it to run an *executable* (as opposed to a *script*), you need to say bash -c FLEXPART_GFORTRAN. You might try strace on that. In addition to the objdump suggestion. I have a moment to expand on this a little. The 80-byte read we saw was bash looking at the beginning of what it that was supposed to be a script (not a binary) and seeing if it really appeared to be a script. I did not look like a script, so bash gave up. (It checks whether the first line is all printable characters or white space.) Best -- Eliot Moss Hmm, wonder why bash would interpret it as a script. Anyway, I will get back to you later with output from strace and objdump. Cheers, kåre
Re: Problem with execution of binary file
On fr., 2011-11-04 at 05:50 -0500, Eliot Moss wrote: On 11/4/2011 3:50 AM, Edvardsen Kåre wrote: On 11/3/2011 4:56 PM, Eliot Moss wrote: Ok, so here's one thing about bash: to get it to run an *executable* (as opposed to a *script*), you need to say bash -c FLEXPART_GFORTRAN. You might try strace on that. In addition to the objdump suggestion. I have a moment to expand on this a little. The 80-byte read we saw was bash looking at the beginning of what it that was supposed to be a script (not a binary) and seeing if it really appeared to be a script. I did not look like a script, so bash gave up. (It checks whether the first line is all printable characters or white space.) Best -- Eliot Moss Hmm, wonder why bash would interpret it as a script. Anyway, I will get back to you later with output from strace and objdump. Because you did not specify -c ... EM I'm still learning :) Anyway, I've installed two versions of cygwin on the same machine - the first was installed around Oct. 3 and the second one from a few days ago. Compiling exactly the same software on both versions gives success on the older installation and failure on the newer one. Could it be that newer versions of some libs/compilers have bugs? Something different between those two versions is for sure causing the problem. Oviously, I'm using gfortran for building FLEXPART_GFORTRAN but I've also installed from source the latest version of jasper and grib_api libs (required by my FLEXPART software), and I'm not sure in detail what is involved in building those libs. Do you have any immediate idea of what could be the potential problem? Cheers, Kåre
Re: Problem with execution of binary file
On to., 2011-11-03 at 14:01 +0100, Edvardsen Kåre wrote: On Nov 3 12:20, Edvardsen KÃre wrote: I keep getting the cannot execute binary file and don't understand why. I have compiled same software on two different machines, but only one of the binaries work (it works on both machines). The successful machine is a HP laptop with W7 Pro, the other unsuccessful is a HP desktop in a AD network domain with W7 Enterpr and cygwin is installed with lokal admin rights only, so I keep getting the Your group is currently mkpasswd... message. What about running $ mkpasswd -l -d /etc/passwd $ mkgroup -l -d /etc/group so you don't get this message? I don't know if this may affect the result, but should not, as I can run the other successful binary. I was guided to run strace along with the call to the erroneous binary and the output is pasted below. The problem binary is called FLEXPART_GFORTRAN Can anyone see what's wrong in the strace log? No. What the strace shows is that bash does not even try to fork and then exec FLEXPART_GFORTRAN. Rather, it just opens the file, reads the first few bytes and then prints the error message: 4514 125618 [main] bash 536 open: open (./FLEXPART_GFORTRAN, 0x0) [...] 25 126365 [main] bash 536 open: 3 = open (./FLEXPART_GFORTRAN, 0x0) 209 126574 [main] bash 536 isatty: 0 = isatty (3) [...] 25 126623 [main] bash 536 lseek64: 0 = lseek (3, 0, 1) [...] 24 126710 [main] bash 536 readv: 80 = readv (3, 0x28CA34, 1), errno 0 458 127168 [main] bash 536 open: open (/usr/share/locale/locale.alias, 0x0) [...etc...] For some reason which isn't visible in the strace, bash doesn't even close the file anymore. What does `file FLEXPART_GFORTRAN.exe' print? Corinna First, The university won't let me run the $ mkpasswd -l -d /etc/passwd $ mkgroup -l -d /etc/group with AD rights, so I just have to live with that. Then, file FLEXPART_GFORTRAN.exe prints: PE32 executable (console) Intel 80386, for MS Windows. I'm not even close being an expert on this, but usually I manage to figure out something, but this time I'm totally lost... It's about a month since I built the well working binary on the different machine, and wonder if any upgrades of cygwin software (compilers or anything) since then may have contain some bug. The bad binary is built on a quite fresh cygwin install. Maybe I will try to reinstall cygwin on the successful machine and see if a rebuilt version of the binary fails. Any thoughts on that? Cheers, Kåre
Re: Problem with execution of binary file
On to., 2011-11-03 at 08:21 -0500, Eliot Moss wrote: Someone more expert than I am may be able to say more (or correct me if I'm wrong), but it appears that bash opened the file, read 80 bytes, and didn't like what it saw. So: What does file FLEXPART_GFORTRAN.exe say about the file? Or maybe you could give us the first few lines from od -b FLEXPART_GFORTRAN.exe. It's starting to look as if it is not properly built. Or, maybe it got messed with in the process of transfer from the other system. Regards -- Eliot Moss As corinna pointed out, the file is barely red before it's closed. The file command gives PE32 executable (console) Intel 80386, for MS Windows Here is a few lines of od -b output from both the working and bad binary, respectively. Good binary 000 115 132 220 000 003 000 000 000 004 000 000 000 377 377 000 000 020 270 000 000 000 000 000 000 000 100 000 000 000 000 000 000 000 040 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 060 000 000 000 000 000 000 000 000 000 000 000 000 200 000 000 000 100 016 037 272 016 000 264 011 315 041 270 001 114 315 041 124 150 120 151 163 040 160 162 157 147 162 141 155 040 143 141 156 156 157 140 164 040 142 145 040 162 165 156 040 151 156 040 104 117 123 040 160 155 157 144 145 056 015 015 012 044 000 000 000 000 000 000 000 200 120 105 000 000 114 001 017 000 032 067 261 116 000 154 165 000 220 252 072 000 000 340 000 047 001 013 001 002 026 000 354 015 000 240 000 220 022 000 000 322 127 073 000 020 000 000 000 020 000 000 260 000 000 016 000 000 000 100 000 000 020 000 000 000 002 000 000 300 004 000 000 000 001 000 000 000 004 000 000 000 000 000 000 000 320 000 300 315 073 000 004 000 000 041 217 173 000 003 000 000 200 340 000 000 040 000 000 020 000 000 000 000 020 000 000 020 000 000 360 000 000 000 000 020 000 000 000 000 000 000 000 000 000 000 000 400 000 220 152 073 014 016 000 000 000 000 000 000 000 000 000 000 420 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 * 520 000 000 000 000 000 000 000 000 174 222 152 073 030 002 000 000 540 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 560 000 000 000 000 000 000 000 000 056 164 145 170 164 000 000 000 600 010 352 015 000 000 020 000 000 000 354 015 000 000 004 000 000 620 000 000 000 000 000 000 000 000 000 000 000 000 140 000 120 140 Bad binary 000 115 132 220 000 003 000 000 000 004 000 000 000 377 377 000 000 020 270 000 000 000 000 000 000 000 100 000 000 000 000 000 000 000 040 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 060 000 000 000 000 000 000 000 000 000 000 000 000 200 000 000 000 100 016 037 272 016 000 264 011 315 041 270 001 114 315 041 124 150 120 151 163 040 160 162 157 147 162 141 155 040 143 141 156 156 157 140 164 040 142 145 040 162 165 156 040 151 156 040 104 117 123 040 160 155 157 144 145 056 015 015 012 044 000 000 000 000 000 000 000 200 120 105 000 000 114 001 017 000 144 115 261 116 000 130 165 000 220 252 072 000 000 340 000 047 001 013 001 002 026 000 322 015 000 240 000 166 022 000 000 354 273 311 000 020 000 000 000 020 000 000 260 000 360 015 000 000 000 100 000 000 020 000 000 000 002 000 000 300 004 000 000 000 001 000 000 000 004 000 000 000 000 000 000 000 320 000 320 061 312 000 004 000 000 126 346 172 000 003 000 000 200 340 000 000 040 000 000 020 000 000 000 000 020 000 000 020 000 000 360 000 000 000 000 020 000 000 000 000 000 000 000 000 000 000 000 400 000 220 316 311 014 016 000 000 000 000 000 000 000 000 000 000 420 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 * 520 000 000 000 000 000 000 000 000 174 222 316 311 030 002 000 000 540 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 560 000 000 000 000 000 000 000 000 056 164 145 170 164 000 000 000 600 270 320 015 000 000 020 000 000 000 322 015 000 000 004 000 000 620 000 000 000 000 000 000 000 000 000 000 000 000 140 000 120 140 640 056 144 141 164 141 000 000 000 224 220 004 000 000 360 015 000
Re: cannot execute binary file
Are there any debug options or logs to check when you get cannot execute binary file? Cheers, Kåre On ti., 2011-11-01 at 13:00 +, Edvardsen Kåre wrote: On ti., 2011-11-01 at 07:28 -0500, Eliot Moss wrote: On 11/1/2011 5:24 AM, Edvardsen Kåre wrote: I've built from source (gfortran) an application that won't run (cannot execute binary file) and the file command prompts: PE32 executable (console) Intel 80386, for MS Windows. (Yes, chmod 755 is set for the executable...) Here's a wondering: Are the necessary dll's installed properly? Maybe you would see this if the program cannot link its libraries during startup ... Regards -- Eliot Moss I did rebaseall after installing a couple of necessary lib's. All compiling (configure, make etc) goes like nothing's wrong (just a few harmless warnings known for ages for this software). The only real error displayed is the: cannot execute binary file. I'll try to reinstall cygwin as admin to see if things change. Cheers, Kåre
Re: cannot execute binary file
On 11/2/2011 9:10 AM, Edvardsen KÃre wrote: Are there any debug options or logs to check when you get cannot execute binary file? Cheers, KÃre - if is it a permission problem you need to check the ACL permissions see getfacl or ACL permission from windows explorer - if you are missing dll's, you can check with: cygcheck ./nome_of_your_file ldd ./nome_of_your_file Regards Marco cygcheck ./actual_exec_file returns a list of dll's - no error message or anything, just a list of dll's ldd ./actual_exec_file returns ldd: ./actual_exec_file.exe: Excec format error Never seen that one before... Cheers, Kåre
Re: cannot execute binary file
On ti., 2011-11-01 at 07:28 -0500, Eliot Moss wrote: On 11/1/2011 5:24 AM, Edvardsen Kåre wrote: I've built from source (gfortran) an application that won't run (cannot execute binary file) and the file command prompts: PE32 executable (console) Intel 80386, for MS Windows. (Yes, chmod 755 is set for the executable...) Here's a wondering: Are the necessary dll's installed properly? Maybe you would see this if the program cannot link its libraries during startup ... Regards -- Eliot Moss I tried installing everything from scratch and same disappointing result. My next try will be to install cygwin with an earlier gcc-version I know works better with my configure scripts. The two latest verions hangs on $EGREP for some reason... Cheers, Kåre
Problems installing Imaging-1.1.7
I’m not able to install Imaging-1.1.7, and I assume it has something to do with the Tcl/Tk dll’s I’ve tried the various rebase solutions as suggested in the list (and a lot of googling), but no luck whatsoever. Here is the output when trying to run the setup script. $ python setup.py build running build running build_py running build_ext building '_imagingtk' extension gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/usr/include/freetype2 -IlibImaging -I/usr/include -I/usr/local/include -I/usr/include/python2.6 -c _imagingtk.c -o build/temp.cygwin-1.7.9-i686-2.6/_imagingtk.o unable to execute gcc: Bad address gcc: vfork: Resource temporarily unavailable error: command 'gcc' failed with exit status 1 I have successfully installed matplotlib-1.1.0 (with basemap-1.0.1, including geos) grib_api-1.9.9 Then I tried to follow advices through this thread: http://cygwin.com/ml/cygwin/2007-01/msg00498.html but no luck. Does this look familiar to anyone or do you need more info to help me out here? Cheers, Kare
RE: Problems with mkpasswd and mkgroup
What is the contents of the /etc/password and /etc/group files after you run the mkpasswd/mkgroup commands (as administrator)? What user can log in, but isn't in the password file? Is that user local or a domain user? The Windows account name with FULL admin privileges is servicekonto and cygwin was installed from this account which is locally on this client and NOT a domain user. kae026 is the user who can log in, but isn't in the password file. kae026 is a domain user. As admnistrator: $ mkpasswd -l -d /etc/passwd mkpasswd (427): [5] Access is denied. $ less /etc/passwd SYSTEM:*:18:544:,S-1-5-18:: LocalService:*:19:544:U-NT AUTHORITY\LocalService,S-1-5-19:: NetworkService:*:20:544:U-NT AUTHORITY\NetworkService,S-1-5-20:: Administrators:*:544:544:,S-1-5-32-544:: Administrator:unused:500:513:U-STRV8-NTF-00063\Administrator,S-1-5-21-388005049-2988697505-1062046759-500:/home/Administrator:/bin/bash cba_anonymous:unused:1001:513:cba_anonymous,U-STRV8-NTF-00063\cba_anonymous,S-1-5-21-388005049-2988697505-1062046759-1001:/home/cba_anonymous:/bin/bash Guest:unused:501:513:U-STRV8-NTF-00063\Guest,S-1-5-21-388005049-2988697505-1062046759-501:/home/Guest:/bin/bash servicekonto:unused:1002:513:U-STRV8-NTF-00063\servicekonto,S-1-5-21-388005049-2988697505-1062046759-1002:/home/servicekonto:/bin/bash /etc/passwd (END) $ mkgroup -l -d /etc/group mkgroup (369): [5] Access is denied. $ less /etc/group SYSTEM:S-1-5-18:18: Administrators:S-1-5-32-544:544: Backup Operators:S-1-5-32-551:551: Cryptographic Operators:S-1-5-32-569:569: Distributed COM Users:S-1-5-32-562:562: Event Log Readers:S-1-5-32-573:573: Guests:S-1-5-32-546:546: IIS_IUSRS:S-1-5-32-568:568: Network Configuration Operators:S-1-5-32-556:556: Performance Log Users:S-1-5-32-559:559: Performance Monitor Users:S-1-5-32-558:558: Power Users:S-1-5-32-547:547: Remote Desktop Users:S-1-5-32-555:555: Replicator:S-1-5-32-552:552: Users:S-1-5-32-545:545: None:S-1-5-21-388005049-2988697505-1062046759-513:513: /etc/group (END) Regards, Kare -- 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 with mkpasswd and mkgroup
Greetings, Kеre Edvardsen! I've installed cygwin system wide on a client (W7 32b) from an account with full Administrators privileges. However, opening a Bash shell (or xterm) as another user prompts: Your group is currently mkpasswd. This indicates that your gid is not in /etc/group and your uid is not in /etc/passwd The /etc/passwd (and possibly /etc/group) files should be rebuilt. See the man pages for mkpasswd and mkgroup then, for example, run mkpasswd -l [-d] /etc/passwd mkgroup -l [-d] /etc/group Note that the -d switch is necessary for domain users. Before asking too many questions I should inform you that the settings etc. for the various users on the W7 client resides on a separat server. I've tried various suggestions found in the lists, but with no success. Obviously, there is a solution to my problem, but I'm struggling to find the right one. It's in front of your eyes. Don't you see it? mkpasswd -l [-d] /etc/passwd mkgroup -l [-d] /etc/group I wish it was that simple... As I said, I've tried various solutions (you'll find several posts around the topic in the list) but non of them seem to solve my problen. meaning: mkpasswd -l -d /etc/passwd and mkgroup -l -d /etc/group (or using any other flags) does not make any difference... Cheers, Kare
