Root v5-34-03 cocoa

aphecetche · November 16, 2012, 11:10am

Hi,

I’m trying to build Root v4-34-03 on my Mac, which has Xquartz installed (for other reasons than Root), and I would like to force to build without X11, so I’m using :

./configure
–with-clang
–disable-x11
–enable-cocoa

but I get :

/Users/laurent/Alice/Root/v5-34-03/graf2d/cocoa/src/TGCocoa.mm:35:10: fatal error: ‘TGLFormat.h’ file not found
#include “TGLFormat.h”

What do I miss ?

Thanks,

tpochep · November 16, 2012, 1:08pm

–enable-cocoa should be enough (I do not know though, what’s wrong if you combine it with --disable-x11).

matevz · November 19, 2012, 9:49pm

Hi Laurent, Timur,

Habve you got it to work then? The error implies that configure did not enable GL and so the corresponding header files didn’t get copied to $ROOTSYS/include/. This is funny, I’ve never seen it on mac (but often on linux when people don’t have mesa-dev(el) package installed).

Timur, how come TGCocoa needs to include TGLFormat? Should we move some structures out of GL? Or cocoa always needs GL anyway and we should just make sure GL is enabled at some point in configure?

Cheers,
Matevz

tpochep · November 19, 2012, 11:16pm

[quote=“matevz”]Hi Laurent, Timur,

Habve you got it to work then? The error implies that configure did not enable GL and so the corresponding header files didn’t get copied to $ROOTSYS/include/. This is funny, I’ve never seen it on mac (but often on linux when people don’t have mesa-dev(el) package installed).

Timur, how come TGCocoa needs to include TGLFormat? Should we move some structures out of GL? Or cocoa always needs GL anyway and we should just make sure GL is enabled at some point in configure?

Cheers,
Matevz[/quote]

ROOT 5.34.03 configured/compiled successfully. I obviously always need a TGLFormat.h, since we have all enumerators/numbers describing pixel format there. And anyway, it’s a problem with configure script that GL was not enabled/TGLFormat was not copied.

aphecetche · November 20, 2012, 9:01am

Hi,

I guess I have some issues with Xquartz vs Macports, as compilation now goes through but when launching anything graphic I get :

roroot [0] TBrowser b
Error in TGVScrollBar::TGVScrollBar: arrow_*.xpm not found

*** Break *** segmentation violation

Here’s how I configure my root (5.34/03, Mountain Lion 10.8.2) (if I do not use --disable-fink then I get a compilation error “cannot find X1/xpm.h …”

#!/bin/sh

[[ ${GSHELL_ROOT}+set = set ]] || GSHELL_ROOT=${HOME}/alien/api

./configure
–with-pythia6-uscore=SINGLE
–with-alien-incdir=${GSHELL_ROOT}/include
–with-alien-libdir=${GSHELL_ROOT}/lib
–with-monalisa-libdir=${GSHELL_ROOT}/lib
–with-monalisa-incdir=${GSHELL_ROOT}/include
–with-xrootd-incdir=${GSHELL_ROOT}/include/xrootd
–with-xrootd-libdir=${GSHELL_ROOT}/lib
–with-clang
–enable-minuit2
–enable-roofit
–enable-soversion
–disable-fink

tpochep · November 20, 2012, 10:23am

[quote=“aphecetche”]Hi,

I guess I have some issues with Xquartz vs Macports, as compilation now goes through but when launching anything graphic I get :

roroot [0] TBrowser b
Error in TGVScrollBar::TGVScrollBar: arrow_*.xpm not found

*** Break *** segmentation violation

Here’s how I configure my root (5.34/03, Mountain Lion 10.8.2) (if I do not use --disable-fink then I get a compilation error “cannot find X1/xpm.h …”

#!/bin/sh

[[ ${GSHELL_ROOT}+set = set ]] || GSHELL_ROOT=${HOME}/alien/api

./configure
–with-pythia6-uscore=SINGLE
–with-alien-incdir=${GSHELL_ROOT}/include
–with-alien-libdir=${GSHELL_ROOT}/lib
–with-monalisa-libdir=${GSHELL_ROOT}/lib
–with-monalisa-incdir=${GSHELL_ROOT}/include
–with-xrootd-incdir=${GSHELL_ROOT}/include/xrootd
–with-xrootd-libdir=${GSHELL_ROOT}/lib
–with-clang
–enable-minuit2
–enable-roofit
–enable-soversion
–disable-fink[/quote]

I can not reproduce this problem (I do not have an alien), but I have seen this problem with arrow_*.xpm several times in a forum, I think this should be something unrelated to cocoa back-end (in all previous cases people had some problems with an incorrect libAfterimage and/or other image libraries).

aphecetche · November 23, 2012, 1:20pm

Hi,

For the record, I solved the problem by installing graphviz through MacPorts.

Coming back to Cocoa implementation though, please find attached two figures produced using the same macro, one with cocoa version and the other with X11 version. You’ll notice that the exponents (of the x-axis title) are way off in the Cocoa version. Is there a way to fix that ?

Thanks,
cocoa.5.99.01.eps (47.3 KB)
x11.5.34.03.eps (46.6 KB)

tpochep · November 23, 2012, 3:56pm

[quote=“aphecetche”]Hi,

For the record, I solved the problem by installing graphviz through MacPorts.

Coming back to Cocoa implementation though, please find attached two figures produced using the same macro, one with cocoa version and the other with X11 version. You’ll notice that the exponents (of the x-axis title) are way off in the Cocoa version. Is there a way to fix that ?

Thanks,[/quote]

It’s not Cocoa who produces eps/pdf/ps whatever. The bug is somewhere in TText or TTF - it asks TGCocoa about font metrics and after that uses other code to create eps/ps/etc - and I’m pretty sure that font metrics for Quartz 2D onscreen text are not very good for freetype library (or whoever generates ps).

aphecetche · November 23, 2012, 4:02pm

FWIW I just want to mention that onscreen the figures look exactly the same, i.e. it’s not the conversion to eps/pdf that’s involved here.

tpochep · November 23, 2012, 4:05pm

Well, eps and pdf are created by the same code for both X11/Cocoa. Unfortunately, we have (at the moment) some “ambiguity” in a code, and while producing pdf (or ps/eps) TText/TTF is still asking TGCocoa about metrics first and later uses something unrelated to produce glyphs, obviously, they are in a wrong position.

Wile_E_Coyote · November 23, 2012, 4:36pm

If you know the exact place where it asks for the “font metrics” … maybe you could check something. Some time ago I had a similar problem (not related to ROOT at all) -> this problem was specific to some system only (I believe it was CentOS 6 running Xorg-1.10.6, for example).
See the following code: char **MyXListFonts(dpy, nbmax, nbreel) Display *dpy; /* in */ integer nbmax; /* in */ integer *nbreel; /* out */ { char **list; int n; list = XListFonts (dpy, "*-iso88*", nbmax, &n); *nbreel=n; /* si necessaire, on prend un filtre plus large */ if (*nbreel == 0) list = XListFonts (dpy, "*", nbmax, &n); *nbreel=n; if ((*nbreel) > nbmax) (*nbreel) = nbmax; /* just a precaution */ return (list) ; } Note the added line “/* just a precaution */” … although the “XListFonts” routine was explicitly asked to return AT MOST “nbmax” entries, it actually happily returned as many fonts as there existed in “nbreel”. This has then lead to buffers being overwritten, as the code that called this function did not check the returned value (it simply expected that the returned “nbreel” will always be smaller than the given input parameter “nbmax”.)
Maybe there’s a “similar” place somewhere in ROOT … you expect that the returned value will be smaller than “the given maximum”, but on some systems, due to a bug in X11, you get something that’s much bigger.