DLLs: Exported functions in a unit not working?

[tk]

Just wondering about the exports clause.

This does not really export (no export visible in PE viewer):

Code: Pascal  [Select][+][-]

1. library something;
2.  
3. uses test;
4.  
5. end.
6.  

Code: Pascal  [Select][+][-]

1. unit test;
2.  
3. interface
4.  
5. function OIProjectCreate(out ItemHandle:LongWord): Boolean; stdcall;
6.  
7. implementation
8.  
9. function OIProjectCreate(out ItemHandle:LongWord): Boolean; stdcall;
10. begin
11. // do something
12. end;
13.  
14. exports
15.   OIProjectCreate;
16.  
17. end;
18.  

but this does:

Code: Pascal  [Select][+][-]

1. unit test;
2.  
3. interface
4.  
5. uses
6.   Classes;
7.  
8. function OIProjectCreate(out ItemHandle:LongWord): Boolean; stdcall;
9.  
10. implementation
11.  
12. function OIProjectCreate(out ItemHandle:LongWord): Boolean; stdcall;
13. begin
14. // do something
15. end;
16.  
17. exports
18.   OIProjectCreate;
19.  
20. end;

Why is the Classes unit needed there?

No warning without the clause.

Been using the Newpascal edition but this tested on stable fpc 3.0.0.

[Phil]

I see the function OIProjectCreate in Dependency Walker.

.dll is 33,280 bytes when compiled without Classes for x86.

[tk]

Hmm, strange.
Don't see the export now even when compiled with Classes.

Wait...

I press Ctrl+F9 (Run/Compile) and the DLL has 428708 bytes, no exports.
I press Shift+F9 (Run/Build) and the DLL has 429385 bytes, exports there.

What the...

[Laksen]

No, for some reason exports only work when exported from the main library file. So you would just have a long list of exports in the library file instead of each units.

Not sure if that's a bug but it's quite strange I would agree

[tk]

No, for some reason exports only work when exported from the main library file. So you would just have a long list of exports in the library file instead of each units.

Is true, when I move them to the lpr file the exports are always there.
Must be a bug, no such problem in Delphi, will add bug report later.

Unfortunately I can't move them to lpr file because they're already auto generated - as discussed here http://forum.lazarus.freepascal.org/index.php/topic,34431.0.html.
Solution for now - compile only for syntax check, build before use.

[Cyrax]

See this bug report : http://bugs.freepascal.org/view.php?id=16070

[mtanner]

I have a DLL which exports a number of functions, from multiuple units. The exports statements are placed immediately after the Implementation statement in each unit, followed by the actual routines.
Exported functions from Unit A work fine, I can call them from a test rig program.
Exported functions from Unit B cannot be found, test rig fails on starting.

Any further info available on how to get Exports statements to work?

[mtanner]

And they don't seem to work at all if I put the Exports in the lpr file.

[Phil]

And they don't seem to work at all if I put the Exports in the lpr file.

That should work. Please zip up the source files for a simple project that demonstrates the problems you're having and post it here.

[mtanner]

It will take me a little while to build a test sample. The real thing has about 250 functions, so a bit unwieldy for narrowing down a problem.

[Phil]

It will take me a little while to build a test sample. The real thing has about 250 functions, so a bit unwieldy for narrowing down a problem.

Also be sure to use the OS tools for examining library dependencies, etc. I assume you're on Windows, so that would be:

http://dependencywalker.com/

https://technet.microsoft.com/en-us/sysinternals/processexplorer.aspx

Similar tools on Linux and OS X.

[mtanner]

I used to have  autility which listed exported functions for a dll - old and now lost. So I've just got depemdencywalker. It shows my dll is exporting the functions I expect, so I will look for some other error.

The size of the dependency tree is startling, with all kinds of dlls pulled in at lower levels.

[mtanner]

Feeling foolish now. Turns out that the cause of my problem was upper/lower case. Exported function names are case sensitive, so "ElgCAgSl" is not the same as "ElgCAgsl". (Not catchy names I know, but in the context of a large collection of routines, my use of upper/lower case is intended to be fairy meaningful.) I I did know that of course, having learnt the hard way a good few years ago, but did not pay enough attention to it.  Using dependencywalker helped to spot this. Always mortifying to make this kind of elementary error, despite many years of experience.

Alternatively I could have a rant about the idiocy of making names case-sensitive, a recipe for problems if ever there was one!

[Phil]

The DLL needs to support case-sensitive languages (that is, most languages).