On 4/19/2012 23:56, Kai Tietz wrote:
> 2012/4/19 JonY :
>> On 4/19/2012 19:51, MARTIN Pierre wrote:
>>> Dear JonY,
>>>
Fastcall and stdcall are different call conventions, so don't mix them up.
>>> i know, but i tried to see what happenned.
>>>
Seeing your earlier gendef output, _ZN7TotoL
2012/4/19 JonY :
> On 4/19/2012 19:51, MARTIN Pierre wrote:
>> Dear JonY,
>>
>>> Fastcall and stdcall are different call conventions, so don't mix them up.
>> i know, but i tried to see what happenned.
>>
>>> Seeing your earlier gendef output, _ZN7TotoLibC1Ev@4@4 looks very wrong,
>>> how are you b
On 4/19/2012 19:51, MARTIN Pierre wrote:
> Dear JonY,
>
>> Fastcall and stdcall are different call conventions, so don't mix them up.
> i know, but i tried to see what happenned.
>
>> Seeing your earlier gendef output, _ZN7TotoLibC1Ev@4@4 looks very wrong,
>> how are you building the DLL? Maybe y
Dear JonY,
> Fastcall and stdcall are different call conventions, so don't mix them up.
i know, but i tried to see what happenned.
> Seeing your earlier gendef output, _ZN7TotoLibC1Ev@4@4 looks very wrong,
> how are you building the DLL? Maybe you can pass me the source/headers
> off-list.
i did!
On 4/19/2012 09:10, MARTIN Pierre wrote:
> i just tried replacing all __stdcall on my example by __fastcall, and rebuilt
> the test library, re-made the .def / .delayed.a etc. Then the main executable
> can link against the library (Although, the .def looks exactly the same to
> me...), but it c
i just tried replacing all __stdcall on my example by __fastcall, and rebuilt
the test library, re-made the .def / .delayed.a etc. Then the main executable
can link against the library (Although, the .def looks exactly the same to
me...), but it crashes when trying to call the dll object (My deb
Well... Bummer. In the latest version of the Toto test project, i was actually
using __stdcall. But still...
This is from TotoLib.h:
#ifndef TotoLib_h
#define TotoLib_h
#include "TotoLib_Global.h"
class TotoLibOpt TotoLib {
public:
/**/ TotoLibOpt __stdcall TotoLib();
};
#endif
This
> No, your code is requesting versions wothout @nn, but gendef is actually
> finding that the functions are adjusting the stack before returning
> (fastcall or stdcall). gendef can't tell the difference between @0 and
> cdecl though since they look the same.
> You should tell the compiler which cal
On 4/19/2012 02:42, MARTIN Pierre wrote:
> i just put the Toto test project on my mac, and compiled it. It works when
> using -lazy-lTotoLib as well as when using -lTotoLib.
> And if i compile TotoApp using -lazy-lTotoLib and add a debug message in the
> main right before the library will get loa
i just put the Toto test project on my mac, and compiled it. It works when
using -lazy-lTotoLib as well as when using -lTotoLib.
And if i compile TotoApp using -lazy-lTotoLib and add a debug message in the
main right before the library will get loaded, the binary executes without
dependencies pr
Oh and in the test "Toto" project, if i add --assume-stdcall to gendef for
creating the delayload lib for TotoLib, i get linker error on TotoApp:
20:31:13: Starting: "C:\MinGW\mingw-w64\bin\mingw32-make.exe"
C:/MinGW/mingw-w64/bin/mingw32-make.exe -f Makefile.Debug
mingw32-make.exe[1]: Entering
On 4/18/2012 23:26, MARTIN Pierre wrote:
>> Are you building RELib? It should only be used when building it, not
>> when using it. I have no idea what Q_DECL_EXPORT is, you'll need to give
>> more information.
> i am (It is one of the many binaries i maintain). i only use RELib when
> building it
> Are you building RELib? It should only be used when building it, not
> when using it. I have no idea what Q_DECL_EXPORT is, you'll need to give
> more information.
i am (It is one of the many binaries i maintain). i only use RELib when
building it of course.
About the Q_DECL_EXPORT macro, it get
On 4/18/2012 21:44, MARTIN Pierre wrote:
> JonY,
>
>> I checked it against your def file, looks like it's
>> __ZNK2RE6Engine13loadedPluginsEv@4, not
>> __ZNK2RE6Engine13loadedPluginsEv, I'm not sure how non-delay lib is
>> linking successfully.
> Thank you very much for digging further into this i
JonY,
> I checked it against your def file, looks like it's
> __ZNK2RE6Engine13loadedPluginsEv@4, not
> __ZNK2RE6Engine13loadedPluginsEv, I'm not sure how non-delay lib is
> linking successfully.
Thank you very much for digging further into this issue JonY.
> Did you use the proper call declarati
On 4/18/2012 20:37, MARTIN Pierre wrote:
> Dear JonY and dear users,
>
> i have found another weird clue to my problem.
>
> i just have tried to compile another program of our project that uses the
> same library we are talking about.
> When linking against the libRELibrary.a, everything is swel
Dear JonY and dear users,
i have found another weird clue to my problem.
i just have tried to compile another program of our project that uses the same
library we are talking about.
When linking against the libRELibrary.a, everything is swell. But when linking
against the delay-loaded version,
Dear Kai,
> Well, that it is a bug in delayed-load code might be, but I wouldn't
> assume so. it might be more related to the issue of exporting
> variables (in C++ things like vtables, etc are variables).
All right, but in this case why is my library working in non-delayed mode? If
it was relat
Dear JonY,
> OK, so linking and running works if done without delay loading? If so,
> it might be a bug in the delay loading code.
Ok. Would you help me to solve it in the source code if it is so?
> For the linker command, show both.
Ok. Here you go:
1) This is the linker command used when compil
Hello,
Well, that it is a bug in delayed-load code might be, but I wouldn't
assume so. it might be more related to the issue of exporting
variables (in C++ things like vtables, etc are variables).
As you describe that linking works, but startup simply does nothing,
it might be interesting to see
On 4/18/2012 09:38, MARTIN Pierre wrote:
> Dear JonY, dear list readers,
>
>> Try using gendef -a, also, try using regular non-delay lib as a test.
> if i compile my library and then generate the .a with a def from gendef with
> the
> --assume-stdcall option, then i'm unable to link against my l
Dear JonY, dear list readers,Try using gendef -a, also, try using regular non-delay lib as a test.if i compile my library and then generate the .a with a def from gendef with the --assume-stdcall option, then i'm unable to link against my library.i get a lot of messages like this (When i compile a
On 4/18/2012 00:22, MARTIN Pierre wrote:
> Hello list readers,
>
> i'm a newcomer to this list. i'm Pierre, and i've been playing with mingw-w64
> for the past 3 days. i have been gathering help from the original mingw
> project list, the guys were very helpfull here. So now i'm facing more
> m
Hello list readers,
i'm a newcomer to this list. i'm Pierre, and i've been playing with mingw-w64
for the past 3 days. i have been gathering help from the original mingw project
list, the guys were very helpfull here. So now i'm facing more mingw-w64
issues, i'm subscribing to this list upon ad
24 matches
Mail list logo
