If you need additional resources then those have to be added to the Jar as well and you need to load them properly. Most likely that will mean using Class.getResourceAsStream or a similar function. How you add the resources in the first place will largely be a question of the build system you are using.
It should also be noted that using "cmath.h" is in general inadvisable when working with C++. C++ has the "cmath" header. Not only does it respect namespaces, it also has several useful overloads for types other than just doubles.
I assume you are trying to compile it with gcc or something like that? The problem then could be that this only causes a warning on MSVC, while gcc decides to treat the (obvious) problem as an error. It's possible you could pass some flag to gcc to not treat it as an error but a better path would be to check the library's mailing list/forum on information how to deal with that. Should it turn out to be something like "we really just compile on MSVC and ignore warnings" then I would suggest to find a different library to use. That will not end well any which way.
in the bin\debug folder of your Project is all the dlls and content files. these are all you need. pop them into a ZIP file or use a program like InnoSetup to create an installer (.msi)
I'm not sure about the specifics of PhysX. but if anything needs to be "installed" for the game to work, you need to include a way of installing them.
It will almost never work to transfer Debug builds of your application to any other machine. There is no redistributable for the Debug runtime, the only machines on which it can work at all are ones which have a similar development environment installed.
It's more doable when statically linking to the runtime but even then moving Debug builds around is almost certainly a horrible idea.
There is no magic bullet for this. If you link a library dynamically you need to either install it as a system library (for your average game support library, that hardly ever to never happens) or put the DLL next to the application executable. If any of those libraries or your game need any data files, they need to be placed correctly as well ('correctly' entirely depends on the libraries you are using and how you load your own resources).
If you are using MSVC you will most likely have to install the correct runtime on the target machine as well (if you are asking this question, static runtime linking almost certainly has not crossed your mind). How exactly to get the runtime on the target machine depends on the exact version of MSVC. Some require installers. Some allow just copying the DLLs next to the application. Some may appear to work by copying the DLLs next there but are subtly broken.
Physx might actually be one of those game libraries which has to be officially installed, but check the documentation there.
There are several installer generators around to automate the installer steps and compress all files into a single exe/msi. I know a bit InnoSetup but don't really have much reference to compare it against what else is out there.
You should be able to retrieve the complete path to your application either by inspecting argv which is passed to the main entry function or by combining the Windows API functions GetModuleHandle and GetModuleFileName.
Different operating systems follow different naming conventions for certain file types -- the .lib files you're seeing are the files you need on Windows, and the information you're seeing online about .a files refers to the same files on Linux or Unix systems.
Actually, when using MinGW or its derivatives most libraries will obey the libXXX.a pattern even on Windows.
You are asking other people to help you, but at the same time you are actively sabotaging their attempts to do so by supplying fake information. Just because you cannot read the strings does not mean no one else can. And while I'm very far from an expert of individual compiler's C++ name mangling, just be glancing at the strings you can verify it's indeed SFML functions missing. I suggest for the future to try and find humour in things that do not actively sabotage other people's attempt to help you.
Nevertheless, the solution of my original post still stand: download whichever precompiled distribution is for your compiler or build the library yourself. I do not know if there is a precompiled distribution of SFML for your preferred flavour of MinGW, but the last time I tried it compiling it yourself was extremely easy.
Assume you have a simple cube. In the most basic case that means 8 vertices and 6 faces. If you want to render it using either OpenGL or Direct3D using canonical lighting you will usually need to create a mesh with 24 vertices and 12 faces. You could also end up with 36 vertices and 12 faces (more vertices but we don't need an index buffer - might actually be a good idea for such a simple mesh).
Depending on the file format you chose any of these numbers up there could be stored in the file. None of them are wrong for our little cube.
Without knowing anything about the mesh you have, how you generated normals (and similar vertex attributes like texture coordinates) for it and which file format you chose there is really not much more than "looks about okay" anyone can say.
That said, I strongly suggest you stick to simple meshes while learning. There is no big difference in getting a 10000 vertices bullet or a 8 vertices cube to load and render correctly. But it makes a huge difference when you can just look at values in the debugger and immediately see whether they are sensible or not.
I'm not familiar with that particular mesh format but it seems to contain at least two different materials. In general that would force Assimp to split the mesh into two submeshes.
Furthermore, if you use Assimp to generate normals, how exactly do you do it? What does the documentation tell you about it? The simplest way to generate normals would be to do it per-face. Of course that will increase the number of vertices.
Edit: According to the documentation:
Generates normals for all faces of all meshes.
This is ignored if normals are already there at the time this flag is evaluated. Model importers try to load them from the source file, so they're usually already there. Face normals are shared between all points of a single face, so a single point can have multiple normals, which forces the library to duplicate vertices in some cases. #aiProcess_JoinIdenticalVertices is *senseless* then.
This flag may not be specified together with #aiProcess_GenSmoothNormals.
So having a much higher vertex count than the number of vertex positions stored in the file would be the expected case.
Edit 2: and have you tried aiProcess_GenSmoothNormals?
It's not really flamebaity, Qt is very difficult to compile/build for Windows platform, has many non-standard tools and code, looks like crap compared to officially approved GUI technologies for Windows and seems to have compatibility issues with Windows 7 and above.
I have built the commercial and OpenSource version of Qt using MSVC and MinGW. I have even built and successfully linked Qt statically using the static runtime even though that's not officially supported. It's not the simplest of builds but far from the worst I have seen and much simpler than some I had to deal with. One part of my day job is looking after a Qt-based application. I have not experienced any compatibility issues with either Windows 7 or Windows 8 so far. Maybe in the more arcane corners, but all the normal stuff works without issues. The only 'non-standard' tool you usually have to deal with is the moc'er. Especially using CMake it integrates into the build process absolutely seamlessly. I don't see much chance for problems down the future either: the C++ standard committee seems extremely reluctant to add anything to the language that breaks existing code, so the worst thing you might have to deal with is that you cannot use some C++XY constructs in your headers you need to moc. And even that is doubtful because parsing the moc'er does is rather lazy and accepts a lot of things that are obviously not valid C++.
While the look of Qt4 is nothing to write home about I haven't really found anyone complaining about it either, unless of course you force a non-native look on it. Qt5 is on a completely different page but I don't have enough experience there yet to comment about it.
[...} without serious rem'ing of stuff, and I've experienced problems with going that route before, you rem out heaps of blocks of code sprinkled across many functions only to forget to un-rem something and bang your head against the wall for hours as to why the D3D driver no longer renders lol
Stop whatever you are doing right now and learn about source control first. SVN, Git and Mercurial (among many others) are completely free to get, use and learn about. Even the simple basics of source control reduce the problem described above to 'exactly nothing'. You can, of course, develop non-trivial software without the aid of version control but that's about as efficient as drilling a hole into your knee and filling it with marmalade before going for the 100m sprint medal. Even if you don't care about branching or any other more interesting possibilities, the ability to compare and restore code to well-defined commit-points alone is something you cannot really live without after having experienced it.
I checked out libRocket in the past but it always looked inactive to me. The last news on their web page is from 2011 and the forum is not exactly active but not completely dead either. Do you have any more experience with that project? Are they still actively developing?