Re: Qt on Mac (was: Getting ready to put out a 4.6 release candidate)

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

On 01/04/2012 04:46 PM, Mojca Miklavec wrote:
> On Wed, Jan 4, 2012 at 23:09, Ethan A Merritt wrote:
>> Mojca Miklavec wrote>
>>
>>> There are at least the following issues:
>>> - configure script is unable to find Qt
>>
>> It uses pkg-config.  If your Qt installation does not come with a set of
>> *.pc files then the configuration script will not work.
>
> Even if it would come with *.pc scripts, Mac OS X doesn't ship
> pkg-config by default, so it would be useless.
>
> But the good news is that it is installed at a default location (with
> default binary installer) and many programs, like Geant4 for example,
> take this into account.
>
> Again, I don't know how to use autotools, but the algorithm is simple enough:
> - check if pkg-config finds Qt
> - if not, check if flags that I mentioned work fine
>
>>> - MOC and UIC are set to an empty string; here "moc" and "uic"
>>> commands work fine, but I don't know why configure script doesn't find
>>> them
>>
>> Because it queries pkg-config to find out where they are.
>>    MOC=`pkg-config --variable=moc_location QtCore`
>>
>> By the way, what version of Qt are you trying to use?
>
> I just realized that I had no Qt installed at all (I only had
> developer tools which are installed at some weird location), so I
> installed the latest version, 4.8.0, but I don't think that it really
> matters. I was testing it long ago (around July when 4.8.0 wasn't
> available yet, see "Any chance to fix gnuplot on mac?" thread, but
> there was some additional private conversation with Jérôme Lodewyck
> who helped me solve some issues) with exactly the same outcome.
>
> If needed, I can probably figure out how to uninstall 4.8.0 and
> install 4.7.*, but that won't help solve the two problems with
> compiling (and last time when I tried it there were exactly the same
> problems with running it).
>
>> I've just been debugging configuration problems with Qt 4.7.4, where it turns
>> out that I need to do the same thing in order to pick up locations for
>> the rcc and lrelease utilities.
>>
>>> - if I fix the two above, qt terminal compiles fine, but I cannot plot anything:
>>>
>>> gnuplot>  plot sin(x)
>>> The process has forked and you cannot use this CoreFoundation
>>> functionality safely. You MUST exec().
>>> Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__()
>>> to debug.
>>
>> No idea what that's about. It is clearly some OSX weirdness.
>> Googling that error message turns up this totally bizarre advice:

The SMB probably means Samba server, which is a Windows emulation thing, 
I think.  This is probably just a consequence of the change that Mojca 
has found below.


> Last time I didn't find anything useful either. However google now
> pointed me to the following:
>
> http://gitorious.org/~friesoft/dinjam/friesoft-development/blobs/master/src/sources/data/standarddirs_mac.cpp
>
> /**
>   Calling CoreFoundation APIs (which is unavoidable in Qt/Mac) has
> always had issues
>   on Mac OS X, but as of 10.5 is explicitly disallowed with an exception.  As a
>   result, in the case where we would normally fork and then dlopen
> code, or continue
>   to run other code, we must now fork-and-exec.

So what you are seeing is the exception that OS X is now throwing when 
it sees you fork() and then not exec(), apparently.  My guess is this 
might be a security measure in some way.  (How?  I don't know, just 
guessing.)


> I would be willing to debug, but I have no idea how to do so. I
> created a ticket:
>      https://sourceforge.net/tracker/?func=detail&aid=3469233&group_id=2055&atid=102055
> where I attached crash report (I just realized where systems stores
> crash reports) if that is of any help, but I'm not sure neither how to
> debug nor how to fix anything.
>
> If you tell me how exactly to "exec()" after fork in qt_term.cpp, I
> can test it, but I don't fully understand the code, so I'm not sure
> what exactly to change and how.

It appears that the fork() is in the qt_init() routine:

236        pid = fork();
237	        if (pid < 0)
238	                fprintf(stderr, "Forking error\n");
239	        else if (pid == 0) // Child: start the GUI
240	        {
241	                signal(SIGINT, SIG_IGN); // Do not listen to SIGINT 
signals anymore
242	
243	#ifndef HAVE_QT_47
244	                /*
245	                 * FIXME: EAM Nov 2011
246	                 * It is better to use environmental variable
247	                 * QT_GRAPHICSSYSTEM but this requires qt >= 4.7
248	                 * "raster" is ~5x faster than "native" (default).
249	                 * Unfortunately "opengl" isn't recognized on my 
test systems :-(
250	                 */
251	                // This makes a huge difference to the speed of 
polygon rendering.
252	                // Alternatives are "native", "raster", "opengl"
253	                QApplication::setGraphicsSystem("raster");
254	#endif
255	
256	                QtGnuplotApplication application(argc, (char**)( NULL));


> It is pretty clear that problems start at this line in qt_term.cpp:
>      QtGnuplotApplication application(argc, (char**)( NULL));
> but after this line gets executed, I cannot even printf (whatever I
> put into print, it doesn't get displayed until something semi-crashes
> and printf sometimes starts working afer QApplication* application =
> new QApplication(argc, (char**)( NULL)); again).

I would guess that the line Ethan conditioned isn't active when you 
compile.  That leaves "signal(SIGINT, SIG_IGN);" as the first line after 
the fork, and that is probably a CoreFunction routine itself so doesn't 
throw the exception or odd behavior.  Thus "QtGnuplotApplication 
application(argc, (char**)( NULL));" is the first line of code to follow 
the fork and probably throws the exception.  According to what you have 
found exec() should nearly follow fork() and you can't have all that 
code in between.  Thus as a first test, perhaps try moving the fork 
before the exec(), e.g.,

#ifndef HAVE_QT_47
                 /*
                  * FIXME: EAM Nov 2011
                  * It is better to use environmental variable
                  * QT_GRAPHICSSYSTEM but this requires qt >= 4.7
                  * "raster" is ~5x faster than "native" (default).
                  * Unfortunately "opengl" isn't recognized on my test 
systems :-(
                  */
                 // This makes a huge difference to the speed of polygon 
rendering.
                 // Alternatives are "native", "raster", "opengl"
                 QApplication::setGraphicsSystem("raster");
#endif

                 QtGnuplotApplication application(argc, (char**)( NULL));

                 // Make sure the forked copy doesn't trash the history 
file
                 cancel_history();

                 // Load translations for the qt library
                 QTranslator qtTranslator;
                 qtTranslator.load("qt_" + QLocale::system().name(), 
QLibraryInfo::location(QLibraryInfo::TranslationsPath));
                 application.installTranslator(&qtTranslator);

                 // Load translations for the qt terminal
                 QTranslator translator;
                 translator.load("qtgnuplot_" + 
QLocale::system().name(), QTGNUPLOT_DATA_DIR);
                 application.installTranslator(&translator);

	        pid = fork();

	        if (pid < 0)
	                fprintf(stderr, "Forking error\n");
	        else if (pid == 0) // Child: start the GUI
	        {
	                signal(SIGINT, SIG_IGN); // Do not listen to SIGINT 
signals anymore
	                // Start
	                application.exec();
	                exit(0);
	        }


That may fail because of dependence on the fork() being called before 
some of those other routines, but it's a start.  (If it fails, try 
moving the application.exec() up near the fork, but you'll have to leave 
behind the exit(0) otherwise the translations will be missing.)

Dan