problem with crosscompilation of dll-s under linux with mingw

New comment
 

Hello

I'm near desperate trying to make MT4 work with dll.

After some struggle I'm able to compile windows dll-s under linux with mingw-gcc compiler.

But there is problem with using them with MT4.


when I declare function like this:

extren "C" __declspec(dllexport) int __stdcall test_func()

...name is mangled with "@0" suffix and MT4 can't see it giving Error 127 in log file.


When I declare like this:

extren "C" __declspec(dllexport) int test_func()

...name is not mangled and it works!


But, when I try to put any parameter:

extren "C" __declspec(dllexport) int test_func(int x)

...MT4 terminal crashes (crash is not caused by bug in function code; body is just "return 0;")


When I don't use extren "C" name is mangled in C++ style so MT4 has no chance to find it.


Anybody can help?


best regards for all

 
froff:

I'm near desperate trying to make MT4 work with dll.

After some struggle I'm able to compile windows dll-s under linux with mingw-gcc compiler.

But there is problem with using them with MT4.

Anybody can help?

I use VC++ 2008 so I am not sure, but in the past I had a similar problem and the suggestion in the following thread solved it:

https://www.mql5.com/en/forum/102300

 
froff:

After some struggle I'm able to compile windows dll-s under linux with mingw-gcc compiler.

[...] ...name is mangled with "@0" suffix and MT4 can't see it giving Error 127 in log file.

See http://www.willus.com/mingw/yongweiwu_stdcall.html. As with Visual Studio, the simplest answer seems to be to use a .def file to list the functions being exported. For example, have a look at the ExpertSample.def file in MT4's experts\samples\DLLSample directory.

 
froff:

Hello

I'm near desperate trying to make MT4 work with dll.

After some struggle I'm able to compile windows dll-s under linux with mingw-gcc compiler.

But there is problem with using them with MT4.



There is NO way around declaring the functions as stdcall.

Any other calling convention simply *must* fail. If you are already using gcc then you might be interested in entirely getting rid of having to use the ancient clumsy C/C++ language with it's clumsy and cumbersome function export syntax and instead use the pascal frontend gnu-pascal (gpc) for gcc or even better a native pascal compiler like FPC and write your DLLs in Object-Pascal instead. Here is a thread that will get you started: http://www.forexfactory.com/showthread.php?t=219576

There seems to be some unknown force that forces people into thinking they always have to use C/C++ for producing native code, there would not be any better alternative. Nothing could be farther from the truth. Pascal will let you do the same things with a much clearer syntax, less work, less errors (strict type safety), has powerful OOP features while still providing all the low level stuff, even seamless integration of inline assembler blocks directly in the pascal source, while being just as efficient and fast as C. I can hardly imagine any valid reason for torturing yourself with C/C++ while you could just as well comfortably use Object-Pascal for the same jobs.

For cross compilation with FPC under linux you will need the package fp-crosswin32

 
7bit:


There is NO way around declaring the functions as stdcall.

Any other calling convention simply *must* fail. If you are already using gcc then you might be interested in entirely getting rid of having to use the ancient clumsy C/C++ language with it's clumsy and cumbersome function export syntax and instead use the pascal frontend gnu-pascal (gpc) for gcc or even better a native pascal compiler like FPC and write your DLLs in Object-Pascal instead. Here is a thread that will get you started: http://www.forexfactory.com/showthread.php?t=219576

There seems to be some unknown force that forces people into thinking they always have to use C/C++ for producing native code, there would not be any better alternative. Nothing could be farther from the truth. Pascal will let you do the same things with a much clearer syntax, less work, less errors (strict type safety), has powerful OOP features while still providing all the low level stuff, even seamless integration of inline assembler blocks directly in the pascal source, while being just as efficient and fast as C. I can hardly imagine any valid reason for torturing yourself with C/C++ while you could just as well comfortably use Object-Pascal for the same jobs.

For cross compilation with FPC under linux you will need the package fp-crosswin32


Ha! "--kill-at" switch when linking dll :D

And I'm not going to experiment with exotic languages. I drop pascal in early '90. C++ rocks! :)  

best regards

 

Just a thought and I know it is fundamental but I am just getting in to DLL with the GNU compiler. Do you have this around your code as the experts suggest?


#ifdef __cplusplus
extern "C" {
#endif

Your code goes here ...

#ifdef __cplusplus
}
#endif

 

7Bit

I learnt to program mainframes using Algol 68 in the late 70's then moved on to Pascal but was forced in to "C" for engineering because all the micros were coming frorm the states. I have always thought "C" stands for Crap and C++ for more of the same. Windows was originally written in Pascal and did almost everything it does now installed from 7 floppies. I shall look in to Pascal like you say because C++ gives me a headache. I still think there has been a lack of progress in programming languages over the last 50 years. It should be common place to just enter our requirements in English and not have to worry about syntax just like we don't get involved with optimisation of assembler/machine code. Thanks for the links I am going to check them out.

 
Ruptor:

Just a thought and I know it is fundamental but I am just getting in to DLL with the GNU compiler. Do you have this around your code as the experts suggest?


#ifdef __cplusplus
extern "C" {
#endif

Your code goes here ...

#ifdef __cplusplus
}
#endif





Yes, I know. extern "C" removes C++ style mangling (with many additional letters and other strange characters :) but __stdcall independently adds to clear name "@xx" postfix. "--kill-at" forces ld to name function without this postfix in dll export list.

 
froff:

And I'm not going to experiment with exotic languages. I drop pascal in early '90. C++ rocks! :)

LOL! There is always time to take a short look over the rim of the tea cup. If you already find this strange old cryptic relict of the 80's, this faulty and error prone C++ language "rocking" (are a masochist?) then I'm sure that modern Object Pascal which is so much more cleaner, more powerful and twice as productive (time needed vs. bugs produced) will easily blow you away. ;-)
New comment