GCC .a Linking and BMax
BlitzMax Forums/BlitzMax Programming/GCC .a Linking and BMax
| ||
| Now I've got to the stage where I need to get BMax to link with the TrueVision3d DLL. They supply only a .lib file ( which does not work renamed, before someone suggests ) and there's precious little help or information on the site. So generally speaking, do I have any options without the DLL creator officially releasing a GCC-compatible lib.a? I have tried creating one using pexports and dlltool, but the lib that creates doesn't work either. So when I try to run anything, I just get a huge list of "undefine reference to blah blah" in the debuglog. |
| ||
| Yes. There is a freeware tool that creates .def + .a out of the DLL. You then can link to this a and provide the DLL together with your app. But you will still need to declare all functions within the extern block after importing it. |
| ||
| I've already declared all the functions within an extern block. Any idea what this freeware tool is called? All I can find on Google is references to pexports and dlltool. |
| ||
| Take a look at this post. The third post describes the usage of pexports and dlltool(both belong to the MinGW compiler). |
| ||
| As I said, I've used pexports and dlltool. The resulting .a file does not resolve the linking problems. |
| ||
| Are the extern correctly declared with = .... not only the function name? (function name only works only when you import codefiles but not if you import libraries) did you import the file is the DLL in the same directory as the exe (although this would not give an error at link time but when you run it) |
| ||
| klepto: Er... what post? O_o |
| ||
| There are no Functions exported from the DLL, it's all classes. And I think you're wrong about function names not working anyway because I've done it before. I know how to do this. I did wrap all of HGE, and most of that is all classes too. I'm just looking for another way to make the .a file. |
| ||
| Try making it so they all extend IUnknown (also you'll have to import Pub.Win32). |
| ||
| OK, I think there's something else getting in the way here. Because this DLL is so large, I've split all the bmx and cpp stuff into class-related files. So I have a .bmx and a .cpp for each class as well as one main bmx and one main cpp file which brings it all together. The Main bmx file includes all the other bmx files and imports the main cpp file. The main cpp file #includes all the other CPP files. Is this the wrong way to go about it? It's all being compiled, but is it not being linked correctly? If I import each CPP file individually, I get a bunch of errors about classes being undefined when they're not, so that way I would presumably have to #include all the headers in each individual CPP file which is both messy and prone to error, not to mention including the same thing more than once, bulking out the package if I'm not VERY careful. What's the correct way to be structuring this? |
| ||
If it's any help, here's a couple of the linking errors.C:/Program Files/BlitzMax/Mod/glimmer.mod/tv3d65.mod/tv3d65.debug.win32.a(tv3dwrapper.cpp.debug.win32.o)(.text+0x1357) :tv3dwrapper.cpp: undefined reference To `_imp___ZN9CTVEngine5ClearEb' C:/Program Files/BlitzMax/Mod/glimmer.mod/tv3d65.mod/tv3d65.debug.win32.a(tv3dwrapper.cpp.debug.win32.o)(.text+0x1364) :tv3dwrapper.cpp: undefined reference To `_imp___ZN9CTVEngine6GetFPSEv' So it's definitely the DLL/Lib that's not linking correctly, and not the way I've structured the CPP wrapper. But there's some pretty nasty name-mangling going on in there and I'm not sure why or how to fix it. Any ideas on that? EDIT: And I can't import Pub.Win32 as I've overwritten some of the declarations in that module. Pub.Win32 contains some legacy code which forces you to use ToCString instead of $z and silly stuff like that. I could edit mine, but I can't ask other people to do that as well. |
| ||
| As mentioned, your externs are not correct. You defined the extern variable, but you did not add its decorated name after the = of the extern declaration of the functions. (depending on the used compiler, this declaration differs from a simple function@X where x is the bytesize of the stuff you give in to something like yours above that looks like Visual Studio compiler. The only thing that will not work that simple is .NET stuff as BM has no direct .NET support. But I know that there has been a how to somewhere on these board using an intermedia layer) Btw: I would not have overwritten Win32. The change you made means that some of BMs own stuff simply can break for no obvious reasons, as it is a BM core module. You better had an additional Win32 which did it the way you want it. |
| ||
| I said this before, but apparently I wasn't clear. There are NO EXTERNS for the DLL. I do not call the DLL from BlitzMax, because there are no functions exposed to call. It's all classes. I call C++ functions from BlitzMax. The C++ functions include the class headers and call the class members. If you read the errors, you'll see that the link errors are being flagged in tv3dwrapper.cpp, not a BMX file. If you look carefully at the errors, you can even see where the :: between class and member should be. As I also said before, I have done this before, so I know the theory is fine. I haven't overwritten Win32,I've redeclared some of what it uses in my own module, so as to NOT overwrite Win32. But I can't import Win32 wholesale any more as it will clash with my module. |
| ||
| Well, one of the reasons you might be having a bit of a problem is because the truevision3d.dll is actually a COM typelib. IF you have MS Platform SDK you can run the tool OLE-COM object viewer to have a better look at it. Also running the Platform tool "depends" you will also notice that the typelib actually depends on the Visual Basic 6 runtime dll MSVBVM60.dll(*shivers*) and DX8VB.DLL . That is for TVSDK 6.2, I don't know how it's done in 6.5 |
| ||
| Thanks Sweenie, but 6.5 is no longer COM based. This is a standard C++ DLL now. |
| ||
| OK so I redefine the problem: The problem then is that you didn't wrap the object correctly in extern. If you want to use the CPP classes you must wrap them in extern as well (it will become tricky, but the irrlicht wrapper from gman is a source if you want to avoid some problems). But even then you can't extend this imported classes. If you want to do that, you will need to link to the .a / .dll and define all the objects in BM and create a wrapping layer. (see irrlicht wrapper) you can not simply import CPP and use it, this only works with c and asm without object. (and even then you need to define all functions using extern) |
| ||
| Dreamora, are actually reading anything I'm writing? I've said numerous times now that I've already written all of the BMax and CPP code necessary. I've already told you that I know what I'm doing in this regard. It's exactly the same thing I did when I wrapped HGE. I've already told you that I've checked everything against Gman's Irrlicht Mod, and that - without even seeing it - I've done it exactly the same way as he did. Yet despite that, you persist in talking to me as though I'm an idiot who has no clue what he's doing. If you don't know how to help, then just stop posting, but continually not reading, and talking to me like I'm an idiot is not helping me. |
| ||
| And just to demonstrate once and for all that I *do* know what I'm doing with the BlitzMax and CPP stuff, I have written and compiled a simple Dev C++ project using TV3D. Included the lib and all the headers, and the linker complains about exactly the same unresolved references. |
| ||
| having a look now |
| ||
| I'd love to, but it's in beta, and only available to people who have purchased a commercial license for it. |
| ||
| Ok. Have you tried running reimp.exe on the lib? If you don't have reimp among your mingw bin-tools, it's part of the mingw binutils. I've used it successfully on some libs but in those cases it was all exported functions, not classes. Might be worth a try though. Don't remember where, but a while ago I also saw a thread there someone was having problems with exported classes in a lib and was finally told to use a demangler tool that was supposed to be part of the microsoft debugging kit. If nothing else works, I guess you'll have to ask the TV3D authors to compile a gcc compatible lib as well. |
| ||
| Slightly unrelated (trying this on Truevision, but haven't gotten a chance to test yet since I need to write some quick wrapper code): Funny. Had that tool this whole time and I never tried it, and now it successfully makes a Cg import library. Sweet. Thanks, Sweenie. |
| ||
| Sweenie: I have tried reimp, yeah. It seems to do exactly the same thing as pexports and dlltool in this case, although I'm told it doesn't always. I'll have a look around and see what I can find out about the demangler tool you mentioned. That sounds promising. I've asked one of the TV3D authors, and he assures me it runs just fine on Dev C++ without any changes, though he has not - as of yet - been able to supply me with a .dev project to learn from. |
| ||
| I have since tried reimp on the static lib, and produced a huge folder full of .obj files. I tried compiling these into an .a file with the ar tool with MinGW, but that compiled lib doesn't work either. Just wondering if this gives anyone any further ideas or clues. The obj files all have the correct names, so I have to assume they're being exported correctly. Not sure if they need to be converted to a different format with one of these MinGW tools before compiling into an a again though. |
| ||
| damn I've come across this once while experimenting with ode... there was some command line switch I needed for ar. I'll take a look and re edit this post... I think is was -s which is the same as running ranlib give that switch a go if your not using it see what happens! |
| ||
| I created the .a with the switches r,c and s, which I think is correct. There are other options available though, so I'll take another look. |
| ||
| ah well, just a thought... |
   |