I'm trying to compile Assimp with MinGW in Code::Blocks, but I get the following errors.
\assimp-3.3.1\assimp-3.3.1\code\StringComparison.h||In function 'int Assimp::ASSIMP_stricmp(const char*, const char*)':|
\assimp-3.3.1\assimp-3.3.1\code\StringComparison.h|144|error: '::strcasecmp' has not been declared|
\assimp-3.3.1\assimp-3.3.1\code\StringComparison.h||In function 'int Assimp::ASSIMP_strincmp(const char*, const char*, unsigned int)':|
\assimp-3.3.1\assimp-3.3.1\code\StringComparison.h|193|error: '::strncasecmp' has not been declared|
While searching I've found out that the two functions in question (strcasecmp and strncasecmp) are in fact declared in string.h which is included in the header of StringComparison.h. I've also managed to get strings.h, the file which they originally belong to, but including that didn't solved the issue either.
While searching this site I've found out that I'm not the only one struggling with this issue. Another solution I've found suggested to use define statements, because the functions might have a slightly different name, but that didn't helped either.
I just encountered this exact same problem, and this question came up during a Google search for the solution, so I'll document my dodgy solution here:
In the end I got it going just by making multiple small edits to the Assimp source code. Solving the string problem isn't enough to get it to work because it just fails later in the build. I'll list the edits I made below. I recommend making them one at a time and then rebuilding, just in case for whatever reason with your setup some of them aren't required. Note that you can't do model exporting with this solution because of the last edit (to Exporter.cpp) if you really need that you'll have to figure out another way to fix the link errors.
It's not a clean solution and it will probably be superceded by a future version of Assimp, at which point I will just delete it. This is for assimp-3.3.1, built with MinGW:
In StringComparison.h, edit the ASSIMP_stricmp function, commenting out everything except the else clause of the #ifdef:
/*#if (defined _MSC_VER)
return ::_stricmp(s1,s2);
#elif defined( __GNUC__ )
return ::strcasecmp(s1,s2);
#else*/
char c1, c2;
do {
c1 = tolower(*s1++);
c2 = tolower(*s2++);
}
while ( c1 && (c1 == c2) );
return c1 - c2;
//#endif
Do a similar thing in ASSIMP_strincmp.
Next, it throws up an error about ::_fullpath in DefaultIOSystem.cpp. My "fix" for this was just to use comment out everything other the fallback option in this function:
ai_assert(in && _out);
// char* ret;
//#if defined( _MSC_VER ) || defined( __MINGW32__ )
// ret = ::_fullpath( _out, in, PATHLIMIT );
//#else
// use realpath
// ret = realpath(in, _out);
//#endif
// if(!ret) {
// preserve the input path, maybe someone else is able to fix
// the path before it is accessed (e.g. our file system filter)
// DefaultLogger::get()->warn("Invalid path: "+std::string(in));
strcpy(_out,in);
// }
It also complains about snprintf being undefined. Edit StringUtils.h to change the following #define to add an underscore before snprintf:
# define ai_snprintf _snprintf
There's also an error about ::atof not being defined. You can fix this by adding
#include <cstdlib>
to StringUtils.h
This should get it building but there will be a link error in Exporter.cpp (this might be due to my specific CMake setttings because I disabled almost all model formats). I fixed it by commenting out the definition of gExporters and replacing it with this:
Exporter::ExportFormatEntry* gExporters = 0;
After this it built and ran fine. The library files are placed in the code folder. Place libassimp.dll.a in your lib build path and libassimp.dll in the path of your executable.
Of course, you can also get it going by using VisualStudio instead (I didn't because I couldn't be bothered installing it) or by building on Linux (I did this previously and it built fine first go, but I needed to do a Windows port).
I had some problems too but hopefully I was able to solve them. I know this is probably too late to help in particular but I hope someone on the Internet will find this useful. I compile using Code::Blocks 16.01 using gcc 5.3.0.
::strncasecmp not declared in this scope:
You have to include and remove the "::"
::_fullpath not declared in this scope:
I never had to perform the operation of finding a full path, so this one is the one I am the least sure of. But anyway, since I couldn't simply remove everything, I had to find the alternative. That is, using "GetFullPathName".
So, as suggested by MSDN, I included , , , .
I also replace the line :
ret = _fullpath( _out, in, PATHLIMIT );
by
ret = (char*)GetFullPathName(in, PATHLIMIT, _out, NULL);
Should work fine, full path is obtained and error checking is kept too.
vsnprintf not declared in this scope
Just add an underscore _ in front of the function name.
to_string is not a member of std::
I would have that this is the usual bug from using MinGW, but actually, Assimp contains a built-in alternative to std::to_string. You just have to remove the std:: part and it should roll.
Make sure to include in the files in which just removing std:: doesn't work.
test\CMakeFiles\gtest.dir\build.make|109|recipe for target 'test/gtest/src/gtest-stamp/gtest-build' failed| ?
It doesn't matter, you already have your working .dll in the "code" folder ;)
I was using Cygwin and encounter the same error, using strncmp and strcmp worked, guessing it is something to do with the libraries (ANSI C++) currently implemented for Cygwin or being used by your project. Not sure though, just wanted it to work for the moment...
Related
See below for the following code, and below that, the error that follows.
std::string source = "C:\\Users\\cambarchian\\Documents\\tested";
std::string destination = "C:\\Users\\cambarchian\\Documents\\tester";
std::filesystem::path sourcepath = source;
std::filesystem::path destpath = destination;
std::filesystem::copy_options::update_existing;
std::filesystem::copy(sourcepath, destpath);
terminate called after throwing an instance of 'std::filesystem::__cxx11::filesystem_error'
what(): filesystem error: cannot copy: File exists [C:\Users\cambarchian\Documents\tested] [C:\Users\cambarchian\Documents\tester]
Tried to use filesystem::copy, along with trying different paths. No luck with anything. Not too much I can write here as the problem is listed above, could be a simple formatting issue. That being said, it worked on my home computer using visual studio 2022, however using VS Code with gcc 11.2 gives me this issue.
Using:
filesystem::copy_file(oldPath, newPath, filesystem::copy_options::overwrite_existing);
The overloads of std::filesystem::copy are documented. You're using the first overload, but want the second:
void copy(from, to) which is equivalent to [overload 2, below] using copy_options::none
void copy(from, to, options)
Writing the statement std::filesystem::copy_options::update_existing; before calling copy doesn't achieve anything at all, whereas passing the option to the correct overload like
std::filesystem::copy(sourcepath, destpath,
std::filesystem::copy_options::update_existing);
should do what you want.
... it worked on my home computer using visual studio 2022 ...
you don't say whether the destination file existed in that case, which is the first thing you should check.
I put the copy_options within the copy function but it didn't work so I started moving it around, I probably should have mentioned that.
Randomly permuting your code isn't a good way of generating clean examples for others to help with.
In the rare event that hacking away at something does fix it, I strongly recommend pausing to figure out why. When you've hacked away at something and it still doesn't work, by all means leave comments to remind yourself what you tried, but the code itself should still be in a good state.
Still doesn't work when I write std::filesystem::copy(sourcepath, destpath, std::filesystem::copy_options::recursive)
Well, that's a different option, isn't it? Were you randomly permuting which copy_options you selected as well?
Trying recursive and update_existing yields the same issue.
The documentation says
The behavior is undefined if there is more than one option in any of the copy_options option group present in options (even in the copy_file group).
so you shouldn't be setting both anyway. There's no benefit to recursively copying a single file, but there may be a benefit to updating or overwriting one. If the destination already exists. Which, according to your error, it does.
Since you do have an error explicitly saying "File exists", you should certainly look at the "options controlling copy_file() when the file already exists" section of the table here.
Visual Studio 2022 fixed the problem
Can anyone tell me where I'm going wrong here?
I'm using C++ bulder 10.2 (clang compiler). From IDE menu I've selected File|New|Dynamic Link Library and chosen compile as C with no dependencies. I've then added sqliteFcts.c and made the sqliteFcts.dll library. It all compiles fine.
Contents of sqliteFcts.c.
#include <sqlite3ext.h>
SQLITE_EXTENSION_INIT1
#ifdef _WIN32
__declspec(dllexport)
#endif
int sqlite3_sqliteFcts_init(
sqlite3 *db,
char **pzErrMsg,
const sqlite3_api_routines *pApi
){
int rc = SQLITE_OK;
SQLITE_EXTENSION_INIT2(pApi);
return rc;
}
// My code is above. Code below was created by the IDE
#pragma argsused
int _libmain(unsigned long reason)
{
return 1;
}
From my own app I try to use the dll with the following code
int rc;
sqlite3_db_config(db,SQLITE_DBCONFIG_ENABLE_LOAD_EXTENSION,1,&rc);
rc=sqlite3_load_extension(db,"C:/temp/sqliteFcts.dll",0,&buf);
I get the error message "The specified procedure could not be found". From what I've read windows expects _libmain to be the Entry Point but sqlite expects sqlite3_sqliteFcts_init to b e the Entry Point and I've no idea how to resolve that or if that is even the problem.
I finally got it working but with a loose end.
Firstly in this line
rc=sqlite3_load_extension(db,"C:/temp/sqliteFcts.dll",0,&buf);
I supplied a null for the 3rd parameter (the entry point) thinking sqlite would resolve this however sqlite would've supplied sqlite3_sqlitefcts_init (note lower case f) as the entry point so, inevitably, the function wouldn't be found. The line should read
rc=sqlite3_load_extension(db,"C:/temp/sqliteFcts.dll","sqlite3_sqliteFcts_init",&buf);
That said, it still didn't work. After advice I received on the sqlite forum I downloaded Dependency Walker and found the function listed as _sqlite3_sqliteFcts_init (note opening underscore) although I've no idea why. Anyway, I changed the above line to
rc=sqlite3_load_extension(db,"C:/temp/sqliteFcts.dll","_sqlite3_sqliteFcts_init",&buf);
and it worked. That was for a 32 bit implementation. I later discovered that when it was compiled as a 64 bit app the opening underscore wasn't required. If anyone can throw any light on this quirk I'd be grateful.
Ok, so I want to use gstreamer library.
1. Situation
I have some code:
#include <gst/gstpipeline.h>
#include <gst/gst.h>
...
GstElement* pipe = gst_pipeline_new("PipeName");
Where gst_pipeline_new is declared in gstpipeline.h:
GstElement* gst_pipeline_new (const gchar* name) G_GNUC_MALLOC;
where non obvious "things" :) are defined somewhere in the system:
typedef struct _GstElement GstElement; // gstelement.h
typedef char gchar; // gtypes.h
#define G_GNUC_MALLOC __attribute__((__malloc__)) // gmacros.h
2. Problem
Since I use make for building I have no errors during compilation and linking. Program itself runs OK as well. However...
In Eclipse IDE I have the following error:
Description Resource Path Location Type
Invalid arguments '
Candidates are:
_GstElement * gst_pipeline_new(const ? *)
' file.cc /path/to/file line 106 Semantic Error
I added all include directories which are specified in Makefile to eclipse project configuration (Project->Properties->C/C++ General->Paths and Symbols->Includes->C++). Of course it's a C++ project.
3. Question
How to get rid of that Eclipse error? I have no clue how to do this... And it drives me mad since now I use some legacy code and I have around 100 errors like this one.
So far I've tried:
casting either by reinterpret_cast<>() or C-like casting to const gchar*
adding typedef char gchar at the beginning of the file - before any other include!
including gtypes.h (gchar is defined there) - also before any other include
redeclaring `_GstElement gst_pipeline_new(const gchar* name)'
Nither of those helped...
To me it looks like Eclipse does not see the gchar type since it says that the candidate is _GstElement * gst_pipeline_new(const ? *) Where ? substitutes the real type. But I have no idea how to make (or event force :)) Eclipse to see it...
Most probably eclipse just doesn't know about your include paths (for this specific library) and complains about the unindexed types and declarations.
You can add them under 'Project->Properties->C++ General->Paths and Symbols'
If this doesn't help, you can also switch off semantic error checking (see Code Analysis), either in whole or for particular error types.
As g-maulik suggested, It seems that it was really an indexer problem. After increasing the indexer cache limits everything works fine.
Go to Window->Preferences->C/C++->Indexer tab cache limits and increase (might be machine dependent):
Index Database cache:
Limit relative to the maximum heap size: 15%
Absolute limit: 128 MB
Header file cache:
Absolute Limit: 128 MB
I’m using the following code to delete an empty folder on Linux:
bool removeFolder (const QString& path)
{
QDir dir(path);
assert(dir.exists());
return dir.rmdir(".");
}
For some reason it sometimes returns false (for specific folders, but those folders don’t seem to be wrong in any way). If I subsequently use ::rmdir from <unistd.h> to remove the same folder, it succeeds.
How can I tell why QDir::rmdir is failing?
This never happened on Windows so far, QDir::rmdir just works.
Confirming: works on windown, fails on linux.
Reading the "rmdir" doc in <unistd>, here https://pubs.opengroup.org/onlinepubs/007904875/functions/rmdir.html, it says there that "If the path argument refers to a path whose final component is either dot or dot-dot, rmdir() shall fail." So what's probably happening is that QDir::rmdir() is calling the unistd rmdir() function in linux, and this one fails with ".".
I tried to just use the full absolute path ( QDir::rmdir(absolutePath) ) and it worked; however, i see basically no point in using QDir::rmdir() over unistd's rmdir(), so i''ll stick w/ the unistd rmdir() from now on.
note: QDir::removeRecursively() is a different story: it seems to work okay, and it's way more convenient than going through opendir() and then successive readdir()'s (or the nftw(...FTW_DEPTH...) thingie).
I had the same problem but on Windows, I could not delete an empty directory with QDir().rmdir(path);. This happened on some older hard drive so may be the ancient file system was to blame. But I found a hack:
QFile(path).setPermissions(QFile::WriteOther); // this works even for dirs
bool success = QDir().rmdir(path);
Of course, you should revert the permissions back to original values if the deletion was unsuccessful anyway, but that's a different story.
Try to use this one:
dir.rmdir(dir.absolutePath())
I am compiling a project that uses both ffmpeg and Ogre.
Now on Windows, everything works fine.
But when I want to compile a file with the following line of code:
Ogre::PixelFormat format = Ogre::PF_BYTE_RGBA;
The compiler gives the following error:
error: ‘AVPixelFormat’ is not a member of ‘Ogre’
Which is strange in many ways, as I have not only specified the Ogre namespace with ::, but also there is no AVPixelFormat in Ogre. How does gcc confuse "PixelFormat" with "AVPixelFormat"?
And how can I get rid of that?
I'd love to use int here instead of an enum, but another Ogre function requires format to be in Ogre::PixelFormat.
Preprocess it first using gcc -E, then grep through the file looking for AVPixelFormat or PixelFormat. I suspect you have a #define or a typedef floating around, you just need to find where this happens, and a precompiled source file is the place this will become apparent.
The problem is in avutil/pixfmt.h:
#define PixelFormat AVPixelFormat
This prevents users from using the word "PixelFormat" anywhere in their own code, even if in namespaces.
This is there as a compatibility hack for older software still using the old identifiers.
The solution is quite simple in case you can edit the code. Just add to the C++ code a
#define FF_API_PIX_FMT 0
before including the ffmpeg headers.
This disables the if in the pixfmt.h header:
#if FF_API_PIX_FMT
#define PixelFormat AVPixelFormat
...
Source: https://trac.ffmpeg.org/ticket/4216
P.S. I know the question is old, but somehow I feel that there is no solution and I needed a solution, so I added it.