Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ TheIDE » U++ TheIDE: Compiling, Linking, Debugging of your packages » creating DLLs HOWTO ??
icon5.gif  creating DLLs HOWTO ?? [message #23750] Thu, 19 November 2009 11:56 Go to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
Hi there

i was searching the forum up and down for some kind of practical info on how to build a DLL project, which i.e exports some classes (same as you can do with visual studio) with the current U++ releases. And that using both MINGW and MSC9 (current win SDK proposed during install). There is no/little quite usable info around this issue. So this is a try to put together what i found out so far, this definitely should be xtended and maybe put somewhere in docs..

So far my steps taken are the following:

Asume you have an u++ application, that wants to loadtime bind to a dll, exorting some functionality classes, also created in u++ (the fact that is is difficult and why, like mirek stated, should be cleared somehow, moreover, the fact, that you actually include double code, i.e Core in the dll and Core in the application is ignored for now)

general setup: U++ 1679, Windows 2003 SDK, like stated during install, mingw 4.4.0 (should u++ update to current?) and MSC9


//creating a dll

1) create a core console, creating also the header name it after your dll
2) remove the CONSOLE_APP_MAIN stuff in the main cpp file
3) setup the configuration of package to additionally have DLL flag
4) make your code, your classes and so on.
5) build your dll project, both MINGW and MSC will produce a .dll file (MSC *also* should produce a .lib file, but doesnt, thats why it later wont work, WHY?)

//creating the app project that will use the dll
1) create a ctrllib (with or without main window)
2) in your app header #include <YourDllPackage/YourDllPackage.h>, this should make the dll headers and includes available, together with the class description (take care of really having declaration and implementation in your dll well seperated)
3) in package organizer, for your app package add a library dependencie with rightcklick/new library

4) compile with MINGW: for that purpose you either have to adjust the PATH or buildmethods PATH stuff to make the previously compiled dll available during link time, i simply compied it to my mingw/lib for short try
5) run your application: copy the dll also in the executable folder of your app (build/open output folder), this should work.

4) compile with MSC9: now this is the problem: linker states it wants to have the .lib file which was not generated when compiling the dll. if it had, one needed to copy it somehpw in the package folder of the app package, and also in the output folder, from where the app would run.

i admit, the path stuff and so on is subject to optimize, was just a short shot, but it should work anyway.

DEPENDENCY WALKER: the mingw compiled dll had the exported functions form all the used packages (Core, etc), the MSC dll had NO exported symbols at all

any ideas on how to do that? this is espacially neccessaru when one wants to keep one's code portable and usable on windows and linux..

thanks for help

PS: attached is a TestDll and a TestDllApp package, demonstrating the goal
  • Attachment: TestDll.zip
    (Size: 843.92KB, Downloaded 293 times)
Re: creating DLLs HOWTO ?? [message #23751 is a reply to message #23750] Thu, 19 November 2009 14:30 Go to previous messageGo to next message
chickenk is currently offline  chickenk
Messages: 169
Registered: May 2007
Location: Grenoble, France
Experienced Member
Exporting symbols in DLLs with MSC:

http://msdn.microsoft.com/en-us/library/z4zxe9k8%28VS.80%29. aspx

and (more specifically using .def files)

http://msdn.microsoft.com/en-us/library/d91k01sh%28VS.80%29. aspx

regards,
Lionel
Re: creating DLLs HOWTO ?? [message #23752 is a reply to message #23751] Thu, 19 November 2009 15:20 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
thanks lionell, its not quite the solution to the problem though,


as far as i know, upp is creating def files itself, dynamicly when parsing the obj files. but it seems that does not work anymore or, which is more probable, i am doing something wrong

(look at http://www.ultimatepp.org/forum/index.php?t=tree&th=1829 &)

like already mentioned, MINGW seems to work fine in this sense, but MSC is doing nothing. and, in fact, i'd like to avoid the use of the __declspec(dllimport) /export stuff., if possible.

greets
Re: creating DLLs HOWTO ?? [message #23768 is a reply to message #23752] Fri, 20 November 2009 11:04 Go to previous message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
i could solve the problem with compiling the dll with MSC by using a manual .def file, created from the .map file, which had to be enabled for creation in builder settings of package. so a .lib file could be created during dll recompile, and thus the app could link.

here comes the refined TestDll project, which has a README.txt
hope this will help anyone.

to the upp crew, maybe rethink of generating the def files automatically again?? (in case it was disabled), its just tooo much needed, to export functionality in classes

///the README.txt

the MSC def file is created from the map file, which is to be generated of first compile (enable create map)

content of .map file is something like

....
0001:00009c90 ??0TestDll@@QAE>@XZ 1000ac90 f TestDll.obj
0001:00009cc0 ??_GTestDll@@UAEPAXI>@Z 1000acc0 f i TestDll.obj
0001:00009cc0 ??_ETestDll@@UAEPAXI>@Z 1000acc0 f i TestDll.obj
0001:00009d00 ??1TestDll@@UAE>@XZ 1000ad00 f TestDll.obj
0001:00009d20 ?MyTestFunction@TestDll@@QAEHXZ 1000ad20 f TestDll.obj
0001:00009d40 ??0Nuller@Upp@@QAE>@XZ 1000ad40 f i TestDll.obj
....

you can strip off the unnessessary stuff when pasting the text into excel or openoffice and setting as delimiter the space
the content of the .def file is then something like

EXPORTS
??0TestDll@@QAE>@XZ
??_GTestDll@@UAEPAXI>@Z
??_ETestDll@@UAEPAXI>@Z
??1TestDll@@UAE>@XZ
?MyTestFunction@TestDll@@QAEHXZ
??0Nuller@Upp@@QAE>@XZ

modify your dll package config
create new link option

WHEN: MSC & DLL /DEF:TestDll.def

/recompile, ensure that it really recompiles, change something in your source files (space add or something)

it will error things:
....
TestDll.def : warning LNK4102: export of deleting destructor 'public: virtual void * __thiscall TestDll::`scalar deleting destructor'(unsigned int)'; i
mage may not run correctly
TestDll.def : warning LNK4102: export of deleting destructor 'public: virtual void * __thiscall TestDll::`vector deleting destructor'(unsigned int)'; i
mage may not run correctly
Creating library C:\upp_1679\out\MSC9.Debug.Debug_full.Dll.Mt.Shared.So\TestD ll.lib and object C:\upp_1679\out\MSC9.Debug.Debug_full.Dll.Mt.Shared.S
o\TestDll.exp
TestDll.obj : error LNK2001: unresolved external symbol "public: virtual void * __thiscall TestDll::`vector deleting destructor'(unsigned int)" (??_ETe
stDll@@UAEPAXI>@Z)
TestDll.exp : error LNK2001: unresolved external symbol "public: virtual void * __thiscall TestDll::`vector deleting destructor'(unsigned int)" (??_ETe
stDll@@UAEPAXI>@Z)
C:\upp_1679\out\MSC9.Debug.Debug_full.Dll.Mt.Shared.So\TestD ll.dll : fatal error LNK1120: 1 unresolved externals
....

remove the virtual destructor things, they may not be there, dont know exactly why
??_GTestDll@@UAEPAXI>@Z
??_ETestDll@@UAEPAXI>@Z

recompile again, this should work

in your application, that also has to be compiled with MSC, include only the header of the dll
an add a library dependency in your package organizer (TestDll)
copy the TestDll.dll and .lib into the package folder of the app, it will be able to compile then
copy them also in the output/execution folder, it should be able to start

/////


Previous Topic: Does the automatic .def generation still work??
Next Topic: Console encoding for localized compilers
Goto Forum:
  


Current Time: Thu Apr 25 22:08:41 CEST 2024

Total time taken to generate the page: 0.02768 seconds