Re: cannot find entry symbol mainCRTStartup; defaulting to 00401000 (gnuplot_qt)

[Daniel J S. <dan...@ie...>]

On 05/28/2014 10:30 PM, Tatsuro MATSUOKA wrote:
> --- On Thu, 2014/5/29, Daniel J Sebald wrote:
>> On 05/28/2014 09:03 PM, Tatsuro MATSUOKA wrote:
>>> Hello
>>>
>>> I am trying to build gnuplot for windows with qt terminal on MinGW platform.
>>>
>>> In linking gnuplot_qt.exe, the following warnig appear:
>>>     warning: cannot find entry symbol mainCRTStartup; defaulting to 00401000
>>>
>>> Perhaps this is related to failure in executing qt terminal.
>>
>> Maybe, but I don't think so because the program runs.  That warning is
>> indicating that the linker can't find main(){} for some reason and is
>> making a good guess at it.
>
> Thank you for your reply.
> gnuplot_qt.cpp has apparently a main() function.
>
> <snip>
> #include "QtGnuplotApplication.h"
> #include<QtCore>
> #include<signal.h>
>
> int main(int argc, char* argv[])
> <snip>

Sorry Tatsuro, I could have been clearer.  In the Makefile for is a 
specification that the entry point should be mainCRTStartup:

gnuplot_qt.exe: ui_QtGnuplotSettings.h $(GNUPLOTQTOBJS)
	$(LD) /entry:mainCRTStartup /subsystem:windows $(LDFLAGS) 
/map:gnuplot_qt.map /out:$@ $(GNUPLOTQTOBJS) $(QTLIBS) shell32.lib

The linker is not finding that for some reason and defaults to the 
main(){} function, which is most likely offset 00401000 if one were to 
look at the linker map.

I'm not real familiar with the way Windows launches a program, but here 
is a summary:

http://stackoverflow.com/questions/22934206/what-is-the-difference-between-main-and-maincrtstartup


>>> Terminal type set to 'qt'
>>> gnuplot>   plot sin(x)
>>> Could not connect to gnuplot_qt "qtgnuplot4832" . Starting a new one
>>>
>>> Warning: slow font initializationgnuplot>
>>>
>>> I'm now using Qt-4.8.6 build myself using the same gcc (4.8.2 MinGW-w64 win32) to build
>>> gnuplot and dependencies.
>>
>> This sounds like the issue that came up not too long ago about TrueType
>> fonts taking much longer than they should to load.  There were two
>> TrueType fonts in particular found to be the problem, but I forget which.
>
> Mmmm. Does anyone remember the issue?

I'm sure.  We looked at this one for quite a while thinking we could 
find a solution, but then realized there wasn't a good one if a font 
library takes so long to load.  But who knows?  Perhaps you've found the 
source of the very slow fonts.  (It would be nice, but I'm not counting 
on it.)  Maybe (repeat "maybe") by going directly to main() and 
bypassing the run-time library setup routines at the launch the system 
fonts hash/tree/whatever isn't setup properly and the system has to 
search for a long time to find the fonts rather than jumping right to them.

If you can figure out how to link your system to get rid of the warning 
message, and if that solves the slow font problem, it could lead somewhere.

Dan