- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Any known workarounds? I really need to get valid file descriptors.
Here's some example code that fails only on ICC :
[cpp]SNDFILE *load_sndfile(wchar_t *in_path) { SF_INFO sfinfo; FILE * in_file = _wfopen(in_path, L"rb"); // open file, return pointer is valid and fully usable SNDFILE *sndfile = sf_open_fd (_fileno(in_file), SFM_READ, &sfinfo, 0); // FAILS HERE. sf_open_fd returns // a NULL pointer, only on the ICC build, even though the result of _fileno(in_file) is 4 on both builds return sndfile; }[/cpp]
The same thing happens with an entirely different API when calling mpg123_open_fd(mh, _fileno(in_file))
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
//////////////////////////////////////////
int sf_error (SNDFILE *sndfile) ;
This function returns the current error number for the given SNDFILE. The error number may be one of the following:
enum
{ SF_ERR_NO_ERROR = 0,
SF_ERR_UNRECOGNISED_FORMAT = 1,
SF_ERR_SYSTEM = 2,
SF_ERR_MALFORMED_FILE = 3,
SF_ERR_UNSUPPORTED_ENCODING = 4
} ;
or any one of many other internal error values. Applications should only test the return value against error values defined in
const char* sf_strerror (SNDFILE *sndfile) ;
const char* sf_error_number (int errnum) ;
The error functions sf_strerror() and sf_error_number() convert the library's internal error enumerations into text strings.
int sf_perror (SNDFILE *sndfile) ;
int sf_error_str (SNDFILE *sndfile, char* str, size_t len) ;
///////////////////////////////////////////////////////////////////////
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It returns the error "File contains data in an unknown format."
The puzzling thing is that when doing a read() using fileno(in_file), what's read is correct and identical on all builds. So it seems like it's the two APIs (libsndfile and libmpg123) that somehow mess it up. And of course on the MinGW build the error is "No error."
For libsndfile I just link with the precompiled lib as provided on the site, and for libmpg123 I use late binding at runtime with GetProcAddress() so it only uses the standard DLL file.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you post me small test-case by using
Also, do you mean simply replacing gcc with ICC in MinGW environment results in the error. which versions of gcc & ICC you are using? Are you sure the rest of things all remain same, like what are the steps youare takingto work MinGW with ICC, please list . You may try to workaround, if using -Od (optimization off) works, and gives correct result.
Also, as per your issue, fileno() passes and returns same value, its the libsndfile API that fails?
Please let us know to investigate it better.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am currently struggling with the same issue of calling sf_open_fd in Windows outside Mingw. I have tried using VS08 compiler but am planning to try Intel compiler later as well. From what I currently understand (correct me if Im wrong?), Libsndfile is linked in Mingw against msvcrt.dll C runtime whereas MS links against msvcr90.dll C runtime so the file descriptors you get in your code don't exist for the libsndfile precompiled dll. I am not totally sure if this is the case also with Intel compiler.
Visual Studio seems to make it hard to link to the original msvcrt.dll. I have tried to recompile the libsndfile for msvcr90.dll following this: http://www.mingw.org/wiki/SpecsFileHOWTO but still couldn't get it to work. You will also need to embed MS DLL manifest to the dll.
Please inform if you get some progress in this!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This doesn't look like an icl issue. But your note about the different version of vc runtime libs reminds me something.
Try to add /QvcXX option that matches your Mingw libs. If you don't know, just try from newest /Qvc9 to oldest /Qvc7.1.
Jennifer
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page