minGW eiu 4.0 "can't createwindow" anomaly solved too!
I rebuilt everything -no-managed-mem to workaround a problem
in the current source, minGW win32
be_alloc.c:424:7: error: conflicting types for 'EMalloc'
I'm assuming this is not related to that difference.
my minGW40/bin/eu.cfg had a missing slash typo
in the line -i minGW40/include
so eui4.0 was somehow using minGW41/include
uncovered by running -D SAFE and getting error
'sizeof' (\Eu41mingw\include\std\safe.e:13) has not been declared.
if sizeof( C_POINTER ) = 4 then
once got that sorted out,
demo/win*.exw updated C_TYPES now run as expected everywhere.
the typo had been there for months, so can explain quite a
few problems I had seen with minGW eui4.0, but to be honest,
I have been mostly running exclusively the struct branch.
seems prettly solid, especially with the latest warnings squashed.
error reporting is working better than ever.
merge at will. though I will admit to not having used all the
new syntax in either default 4.1 or struct.
and building the docs needs some tlc in euphoria/tokenize.e to handle
euphoria/debug/debug.e and the dot notation in the memstruct section.
I have posted an incomplete fix that allows the docs to build
but causes failed t_tokenize tests
so it may cause other doc sections to be inaccurate for all I know.
BTW, this include mismatch had little to do with the original bug
report that started this thread. I was really only testing eu41 struct,
and just noted that minGW eui 4.0 was outputting fail messages.
the wrong include file explains away that problem as well.
I mention also, just prior to trying -D SAFE I added -eudir inc
to all shortcuts that I use to test different builds.
that alone should have put the correct eu40/include at the top.
not to mention setting EUDIR in all batch files calling eui/euc
so there could still be something amiss in commandline resolution?
or could be I have no idea how -eudir is meant to be used.
or, more likely, I have too many active EUDIR= & eu.cfg in use.
I will update 4.0 and struct/demo once I get them all converted.
demos 4.0 using pokes instead of memstruct
these are still great demos!
I can probably dig up a backup repo and do a fresh pull to get updated.
still strange to me why only a createwindow error and nothing else.
I was on the way to figuring it out by outputting a
list of C_TYPE wraps to a log file at runtime.
and may have eventually compared the values to std/dll.
I may still not have easily figured out the bad -i include
a filemon session would have shown that EU41/include was utilized
before or instead of EU40/include and been a good indication.
was planning to add some string name output
to associate the name of the constant with the value.
hope Shawn's enum branch leads to first class variable all over.
partial from a log file, running eui4.0
DefWindowProcA
3000001
2000004
3000001
3000001
the new C_TYPES
DefWindowProc = link_c_func(user32, "DefWindowProcA",
{C_HWND, C_UINT, C_WPARAM, C_LPARAM}, C_LRESULT)
this should have been a dead giveaway that something was wrong even by sight.
in both 4.0 & 4.1
C_UINT = #02000004
in 4.0 C_POINTER = C_UINT
in 4.1 C_POINTER = #03000001
now with the includes fixed and using the local C_TYPES
DefWindowProcA
2000004
2000004
2000004
2000004
seems wrong that a bad value could be used in define_c_proc/func.
obviously it was able to be resolved somehow.
typical of the original declarations:
DefWindowProc = link_c_func(user32, "DefWindowProcA",
{C_INT, C_INT, C_INT, C_INT}, C_INT)
I'll still work on the cross checking a little more just for kicks.
unfortunately I am stuck w/gcc 452 for now, minGW 461 builds euphoria fine
but has problems building Qt especially in debug mode.
and it won't link to libs built w/gcc4.5.2
On 12/15/11, Matt Lewis <matthewwalkerlewis@...> wrote:
> On Wed, Dec 14, 2011 at 11:36 PM, m b <eltronis@...> wrote:
>> Matt Lewis <matthewwalkerlewis@...> wrote:
>>> On Wed, Dec 14, 2011 at 7:02 PM, m b <eltronis@...> wrote:
>>>> Update: winwire & taskwire
>>>
>>>> demo winwire
>>>> http://openeuphoria.org/pastey/104.wc
>>>
>>> I forgot to say...you have commit permissions, right? Please fix
>>> those C_ type errors and push the changes up. I think those are fine
>>> to do in the 4.0 branch. Just remember to also put something into the
>>> release notes.
>>>
>> yes,
>> fix them in std/dll?
>
> Hmm...they look fine in there, I think. I thought it was just about the
> demo.
>
>> I have hesitated to push to euphoria because I did a really ugly revert a
>> few
>> months ago and haven't had a chance to get a new repo yet.
>> mercurial is a little bit over the edge forcing every commit to become
>> un changeable.
>
> OK.
>
>
>>>I've been meaning to build the back end with -Werror
>>
>> better than -Wall
>> CC=g++
>> the first complaint is a few void* convert to FILE* or something similar.
>> removing some of the errors and warning would be necessary
>> if there is a hope of building with clang (http://clang.llvm.org/)
>
> Yes, no doubt we're missing casts in a bunch of places. For this
> purpose, I'd probably use -Wall and -Wextra along with -Werror to
> catch lots of stuff. Eventually, I might go for -Wpedantic to see how
> much gcc stuff we're using that's not standard.
>
> Looking at clang's page, I see "gcc compatibility," so in theory (mind
> you, this is the result of a 5 second investigation on my part :-), we
> should be able to use that relatively easily, even if it would require
> some special flags.
>
> --
> Matt Lewis
>
> ------------------------------------------------------------------------------
> 10 Tips for Better Server Consolidation
> Server virtualization is being driven by many needs.
> But none more important than the need to reduce IT complexity
> while improving strategic productivity. Learn More!
> http://www.accelacomm.com/jaw/sdnl/114/51507609/
> _______________________________________________
> Rapideuphoria-develop mailing list
> Rapideuphoria-develop@...
> https://lists.sourceforge.net/lists/listinfo/rapideuphoria-develop
>
|