esheldon / esutil

A variety of python utilities focusing on numerical, scientific, and astrophysical computing

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Installation issues on Windows

GoogleCodeExporter opened this issue · comments

What steps will reproduce the problem?
1. python setup.py install

What is the expected output? What do you see instead?
Should not see any errors, instead:

running install
running build
running build_py
running build_ext
building 'esutil.recfile._records' extension
C:\MinGW\bin\gcc.exe -mdll -O -Wall 
-IC:\Python27\lib\site-packages\numpy\core\include -Iesutil/include 
-Iesutil/htm -Iesutil/htm/htm_src -IC:\Python27\include -IC:\Python27\PC -c 
esutil/recfile/records.cpp -o 
build\temp.win32-2.7\Release\esutil\recfile\records.o
In file included from esutil/recfile/records.cpp:1:0:
esutil/recfile/records.hpp:33:1: warning: missing terminating " character 
[enabled by default]
esutil/recfile/records.hpp:90:1: warning: missing terminating " character 
[enabled by default]
esutil/recfile/records.hpp:105:3: warning: missing terminating " character 
[enabled by default]
esutil/recfile/records.hpp:132:56: warning: missing terminating " character 
[enabled by default]
esutil/recfile/records.hpp:142:3: warning: missing terminating " character 
[enabled by default]
esutil/recfile/records.hpp:169:3: warning: missing terminating " character 
[enabled by default]
esutil/recfile/records.hpp:178:3: warning: missing terminating " character 
[enabled by default]
esutil/recfile/records.hpp:182:3: warning: missing terminating " character 
[enabled by default]
esutil/recfile/records.cpp: In member function 'void Records::DoSeek(npy_intp)':
esutil/recfile/records.cpp:321:43: error: 'fseeko' was not declared in this 
scope
esutil/recfile/records.cpp: In member function 'void 
Records::SkipFieldAsBinary(long long int)':
esutil/recfile/records.cpp:475:41: error: 'fseeko' was not declared in this 
scope
esutil/recfile/records.cpp: In member function 'void 
Records::SkipBinaryRows(long long int)':
esutil/recfile/records.cpp:539:45: error: 'fseeko' was not declared in this 
scope
error: command 'gcc' failed with exit status 1


What version of the product are you using? On what operating system?
This is esutil-v0.5.1 using Windows 7 64 bit and Python 2.7.

Please provide any additional information below.
Thank you very much for any help or assistance you can provide!


Original issue reported on code.google.com by dcerv...@gmail.com on 7 Mar 2013 at 6:59

Thanks very much for the error report.

That is a surprising error; this is a standard library function.

Maybe the version of python on windows does linking differently?

I don't actually have a windows installation, so I can't help you with 
debugging this. Can you perhaps try making a simple program that uses fseeko 
and see if it compiles?

Sorry I can't be more helpful.
-e

Original comment by erin.sheldon@gmail.com on 8 Mar 2013 at 10:55

I'm having the same problem with the latest MinGW packages (gcc 4.8.1).

Here are some useful:

http://stackoverflow.com/questions/9026896/get-large-file-size-in-c
http://kemovitra.blogspot.nl/2012/11/to-fix-large-file-support-issue-with.html
https://mailman.videolan.org/pipermail/libbluray-devel/2010-August/000039.html

I actually had a look in mingw/include/stdio.h and could only find fseeko64 and 
fseek. So in my opinion, the code in doubt (records.cpp) is not portable for 
mingw and should be changed like in the links above.

Original comment by neothema...@googlemail.com on 19 Oct 2013 at 5:55

OK, thanks for the update.  Can you try your suggestion on your local copy and 
see if ti works? If so I'll incorporate your patch.

Original comment by erin.sheldon@gmail.com on 21 Oct 2013 at 5:41

I added the following lines to records.hpp:

#if defined( __MINGW32__ )
#   undef  fseeko
#   define fseeko fseeko64
#endif

With that, the compile error went away. I couldn't link it though, but that is 
another error on my local machine (I wasn't able to compile anything completely 
yet, always getting "undefined reference to `_imp__Py_InitModule4", which seems 
due to mixing debug non-debug libs). So, I think this fix should solve the 
problem.

Original comment by neothema...@googlemail.com on 21 Oct 2013 at 7:11

so you guys (erin et al) didn't even test this on Windows ?

Original comment by webtour...@gmail.com on 24 Nov 2013 at 7:41

I need confirmation from testers if it works on windows.  I don't have a 
windows machine.

Is this something you can test?

Original comment by erin.sheldon@gmail.com on 24 Nov 2013 at 8:11