2012/5/15 MARTIN Pierre
> Ruben,
>
> I applied a patch to make GCC's configure detect a newer CLooG version
> (0.17), and modified two typedefs which are required for a newer ppl
> version. The last change is present upstream already.
>
> Thank you for explaining. Is there a changelog of your wor
Ruben,
> I applied a patch to make GCC's configure detect a newer CLooG version
> (0.17), and modified two typedefs which are required for a newer ppl version.
> The last change is present upstream already.
>
Thank you for explaining. Is there a changelog of your work, or
a git with a set of pat
Op 14 mei 2012 22:27 schreef "MARTIN Pierre" het
volgende:
>
> Dear Ruben,
>
> > Just for reference: no patching done on my side. The only things I
would patch (for release build things) are build related things, which do
not affect the workings of the program at all.
> What could typically be "bu
Dear Ruben,
> Just for reference: no patching done on my side. The only things I would
> patch (for release build things) are build related things, which do not
> affect the workings of the program at all.
What could typically be "build-related things"? Do you mean
the makefiles for instance, ne
2012/5/14 JonY
> On 5/14/2012 19:40, MARTIN Pierre wrote:
> > Dear Kai, JonY, Ozkan and list readers,
> >
> > As suggested by list users, i have filled a bug report right here:
> >
> https://sourceforge.net/tracker/?func=detail&aid=3526537&group_id=202880&atid=983354
> > If you think it's not cle
> Go ahead and make a bug report, thanks. Dlltool for mingw and mingw-w64
> are really the same, I don't think Ruben does any patching for binutils.
Done, right there:
https://sourceforge.net/tracker/?func=detail&aid=3526550&group_id=202880&atid=983354
Thank you all for your help, right now i know
On 5/14/2012 19:40, MARTIN Pierre wrote:
> Dear Kai, JonY, Ozkan and list readers,
>
> As suggested by list users, i have filled a bug report right here:
> https://sourceforge.net/tracker/?func=detail&aid=3526537&group_id=202880&atid=983354
> If you think it's not clear enough, i would like your f
Dear Kai, JonY, Ozkan and list readers,
As suggested by list users, i have filled a bug report right here:
https://sourceforge.net/tracker/?func=detail&aid=3526537&group_id=202880&atid=983354
If you think it's not clear enough, i would like your feedback about
what i could possibly detail about, o
On Mon, May 14, 2012 at 12:54 PM, Kai Tietz wrote:
> 2012/5/13 MARTIN Pierre :
>> Dear Kai, dear list readers,
>>
>> No, gendef seems to add double @ symbol happily. You can file a
>> bug about gendef to our bugtracker for this.
>>
>> i surely will.
>>
>> Simply remove double @ at line end. thing
2012/5/13 MARTIN Pierre :
> Dear Kai, dear list readers,
>
> No, gendef seems to add double @ symbol happily. You can file a
> bug about gendef to our bugtracker for this.
>
> i surely will.
>
> Simply remove double @ at line end. things like ...@12@12 to ...@12.
>
> Done.
>
>
> As long as they ar
On 5/14/2012 03:41, MARTIN Pierre wrote:
> Dear Kai, dear list readers,
>
>> No, gendef seems to add double @ symbol happily. You can file a
>> bug about gendef to our bugtracker for this.
> i surely will.
>
>> Simply remove double @ at line end. things like ...@12@12 to ...@12.
> Done.
>
>> As
Dear Kai, dear list readers,
> No, gendef seems to add double @ symbol happily. You can file a
> bug about gendef to our bugtracker for this.
i surely will.
> Simply remove double @ at line end. things like ...@12@12 to ...@12.
Done.
> As long as they aren't accessed it should work, but better
Hi Pierre,
2012/5/13 MARTIN Pierre :
> Dear Kai, dear list readers,
>
>> See as example the export 'DllMain@12@12'. This is the main-entry of
>> DLL and has just the extension @12 and not @12@12.
>> So this means this symbol gets the extension doubled. Also an good
>> question is here why DLL con
Dear Kai, dear list readers,
> See as example the export 'DllMain@12@12'. This is the main-entry of
> DLL and has just the extension @12 and not @12@12.
> So this means this symbol gets the extension doubled. Also an good
> question is here why DLL contains at all symbols with @ decoration
> in e
Hi,
I think the .def file generated by your DLL is here one reason for this issue.
See as example the export 'DllMain@12@12'. This is the main-entry of
DLL and has just the extension @12 and not @12@12.
So this means this symbol gets the extension doubled. Also an good
question is here why DLL c
Dear list,
As i was looking at the conversation indexed by GMane
here: http://permalink.gmane.org/gmane.comp.gnu.mingw.w64.general/4888
i noticed that my answer to Kai's latest message wasn't there.
That might be due to the fact i attached a 17kB file to
my email, and it might have failed to pass
Just for clarification: In the def file, you will see a few C-compliant
methods. These are the one i call from my main binary, along with DeviceConfig
and Config constructors and destructors.
The only other function called from the main binary is SC::StaticInitializer,
it's a static declaring it
Hmm, I doubt that the code for delay-load support makes a differenceof calling-convention of exports. Only important thing is that thosefunction are declared with proper calling-convention prototype.That's exactly what JonY told me when we attacked this problem (He was of a great help regarding th
2012/5/12 MARTIN Pierre :
> Dear list readers,
>
> i'm enjoying my free time to migrate all my projects on the MinGW-w64
> compiler toolchain.
> i am using Ruben's build right now, and it is working exactly as expected
> (All my project compile as well as the 3rd party project they need).
> My go
Dear list readers,
i'm enjoying my free time to migrate all my projects on the MinGW-w64 compiler
toolchain.
i am using Ruben's build right now, and it is working exactly as expected (All
my project compile as well as the 3rd party project they need).
My goal being to achieve the same thing i wa
20 matches
Mail list logo
