Root on cygwin and gcc 3.3

I have installed root 3.10.02 for cygwin. In general it works very well. There are, however, a few issues I am having (I have gcc 3.3).

  1. Compiler warnings about versions
  2. Unable to build test code and compile certain root scripts
  3. Unable to build root from scratch

I don’t know if all of these problems have to do with my having gcc 3.3. I thought it would be easiest to downgrade my gcc to 3.2 and see what happens, but apparently that is no longer possible. If it is a problem with root and gcc3.3, are there any future plans?

Thanks,
Charles

  1. When I tell root to compile (.L) a file, I get a bunch of the following warnings (although the macro compiles and runs fine):
    :17:1: warning: “GNUC_MINOR” redefined
    :3:1: warning: this is the location of the previous definition

(I am assuming that this version of root was built with gcc 3.2 and I have 3.3 and that is the cause)

  1. In this case, I got this error message when trying to build ‘Tetris’ in the test area. I have also seen this error message when trying to compile a root script (.L)
    cplager@pointyjr> make Tetris
    g++ -shared -D_DLL -Wl,–export-all-symbols -O -Wl,–enable-auto-import Tetris. TetrisDict.o -L/usr/local/bin/root//lib -lCore -lCint -lHist -lGraf -lGraf3d - Gpad -lTree -lRint -lPostscript -lMatrix -lPhysics -lm -L/usr/local/bin/root//l b -lCore -lCint -lHist -lGraf -lGraf3d -lGpad -lTree -lRint -lPostscript -lMatr x -lPhysics -lGui -lm -o Tetris.dll
    d000038.o(.idata$5+0x0): multiple definition of __imp___ZTV14TSysEvtHandler' d000028.o(.idata$5+0x0): first defined here d000038.o(.idata$6+0x0): multiple definition of__nm___ZTV14TSysEvtHandler’
    d000028.o(.idata$6+0x0): first defined here
    d000039.o(.idata$5+0x0): multiple definition of __imp___ZTV5TIter' d000029.o(.idata$5+0x0): first defined here d000039.o(.idata$6+0x0): multiple definition of__nm___ZTV5TIter’
    d000029.o(.idata$6+0x0): first defined here
    d000042.o(.idata$5+0x0): multiple definition of __imp___ZTV5TIter' d000029.o(.idata$5+0x0): first defined here d000042.o(.idata$6+0x0): multiple definition of__nm___ZTV5TIter’
    d000029.o(.idata$6+0x0): first defined here
    d000217.o(.idata$5+0x0): multiple definition of __imp___ZTV5TIter' d000029.o(.idata$5+0x0): first defined here d000217.o(.idata$6+0x0): multiple definition of__nm___ZTV5TIter’
    d000029.o(.idata$6+0x0): first defined here
    d000218.o(.idata$5+0x0): multiple definition of __imp___ZTV7TQClass' d000032.o(.idata$5+0x0): first defined here d000218.o(.idata$6+0x0): multiple definition of__nm___ZTV7TQClass’
    d000032.o(.idata$6+0x0): first defined here
    d000241.o(.idata$5+0x0): multiple definition of __imp___ZTV5TIter' d000029.o(.idata$5+0x0): first defined here d000241.o(.idata$6+0x0): multiple definition of__nm___ZTV5TIter’
    d000029.o(.idata$6+0x0): first defined here
    d000264.o(.idata$5+0x0): multiple definition of __imp___ZTV5TIter' d000029.o(.idata$5+0x0): first defined here d000264.o(.idata$6+0x0): multiple definition of__nm___ZTV5TIter’
    d000029.o(.idata$6+0x0): first defined here
    d000271.o(.idata$5+0x0): multiple definition of __imp___ZTV5TIter' d000029.o(.idata$5+0x0): first defined here d000271.o(.idata$6+0x0): multiple definition of__nm___ZTV5TIter’
    d000029.o(.idata$6+0x0): first defined here
    d000428.o(.idata$5+0x0): multiple definition of __imp___ZTV14TSysEvtHandler' d000028.o(.idata$5+0x0): first defined here d000428.o(.idata$6+0x0): multiple definition of__nm___ZTV14TSysEvtHandler’
    d000028.o(.idata$6+0x0): first defined here
    d000429.o(.idata$5+0x0): multiple definition of __imp___ZTV5TIter' d000029.o(.idata$5+0x0): first defined here d000429.o(.idata$6+0x0): multiple definition of__nm___ZTV5TIter’
    d000029.o(.idata$6+0x0): first defined here
    d000430.o(.idata$5+0x0): multiple definition of __imp___ZTV6TTimer' d000030.o(.idata$5+0x0): first defined here d000430.o(.idata$6+0x0): multiple definition of__nm___ZTV6TTimer’
    d000030.o(.idata$6+0x0): first defined here
    d000431.o(.idata$5+0x0): multiple definition of __imp___ZTV7TQClass' d000032.o(.idata$5+0x0): first defined here d000431.o(.idata$6+0x0): multiple definition of__nm___ZTV7TQClass’
    d000032.o(.idata$6+0x0): first defined here
    collect2: ld returned 1 exit status
    make: *** [Tetris.dll] Error 1

  2. I attached the errors in ‘make.txt’
    make.txt (46 KB)

Hi,

This was a bug in cygwin. You need to update to a newer version of cygwin (see other post on the subject).

You also have to rebuild ROOT to be able to use it with gcc 3.3

Cheers,
Philippe.

Hi,
There is a really annoying bug in the cygwin 1.5.7.1 (emacs becomes incredibly unstable). Does anybody have a copy of the cygwin snapshot they used to get root to work?
Thanks
Charles

Hi Charles,
yeah, really annoying. The cygwin guys claim it’s resolved in the latest snapshot [cygwin.com] - and if not we’re supposed to send in cygcheck output and emacs.stackdump output.
Axel.

It turns out I was wrong. You can revert to gcc 3.2. For gcc 3.3, they let you downloadn different parts (e.g. g++, g77, etc). For gcc 3.2, you get all or nothing. If you want to go back to 3.2, remove all 3.3 parts (using the cygwin setup.exe) and then install gcc 3.2.

Right, that’s possible. I tried the snapshot cygwin-inst-20040225.tar.bz2, and things seem to get better again - emacs is runing stable, and the bluescreen I got running x3d (right after Rene warned me about cygwin and bluescreens) didn’t show up again. I’ve been using it for several days now, without problems, with gcc3.3 and root cvs.
Axel.

Hi Axel,

I have installed cygwin’s latest version (DLL version: 1.5.9) and “root for XP with Cygwin and gcc3.2” (namely, root_v3.10.02.win32gcc.tar.gz). But, as you guess, the problem is that my g++ compiler is “g++ (GCC) 3.3.1 (cygming special)”. I cannot find gcc 3.2 from cygwin setup (even when removing it completely, as Charles suggested last september). I did not find either the snapshot cygwin-inst-20040225.tar.bz2 (as you recommend), but any way, cygwin’s dll has been updated twice since then! So, I suppose that this snapshot has been integrated into the latest versions.

NB : I even tryed, “with a little help from my friends”, to compile root from sources, refering to your website, but the compilation failed after much work. I kept fighting for a while but I eventually gave up. I went back to the previous installation from binaries.

I.1) I have the same symptoms as Charles :
Every time I compile my scripts with ACLIC, I first get this (four times):

[quote]:17:1: warning: “GNUC_MINOR” redefined
:3:1: warning: this is the location of the previous definition
[/quote]
But this is not a real problem for me, as I can still compile my scripts.

I.2) and if I recompile the script without changing it, ACLIC says :

[quote]Warning in : unmodified script has already been compiled and loaded
Warning in : it will be regenerated and reloaded!

:17:1: warning: “GNUC_MINOR” redefined

g++: /cygdrive/d/documents/these/beamsim/./bernie_c.dll: No such file or directory
Error in : Compilation failed!
[/quote]

I.3) the third recompilation then gives the same output as the first one, etc…

II.1) Another problem is the use of the Divide method of a pointer to a TCanvas.
The following script will work with CINT without any problem.
It can also be compiled with ACLIC but then leads to a [quote]*** Break *** segmentation violation[/quote]
when trying to Divide the canvas. I know that this script is ok and perfectly running on someone else’s root (for linux). So, I really think that this problem is once again connected to my g++ 3.3.1 compiler. Right ?

Here is the script that I compile with the command ".L bernie.C++ " :

[code]#include “TCanvas.h”

void bernie() {
TCanvas *mine = new TCanvas(“mine”,“mine”,700,500);
mine->Divide(1,2);
}
[/code]

Note that there is no segmentation violation with

TCanvas mine("mine","mine",700,500); mine.Divide(1,2);

Any clue to solve these “gcc3.3 -related” bugs ?
Should I wait for the next ROOT release ?

Cheers,
Xavier

Hi Xavier,
could you try the current release v4.00/04, please? I know gcc 3.3 introduced an incompatibility to older root releases, which I fixed on 2004-01-14. This should only matter for linkage (i.e. it might solve your problem II), but who knows… Please let me know whether using 4.00/04 solves your problems, and if not, please run Aclic with gDebug=7, and send the output.

I’m sorry win32gcc took you so much time and effort; I’ll update my page today!
Axel.

I installed the release v4.00/04 but it does not help. Moreover, it seems that the situation is worst, as I can not recover the xterm after root’s crash. But the symptoms/behaviour are the same in every other details.

I hope the attachment will help you !
root4_output.txt (5.49 KB)

Hi,

[quote=“rouby”]I installed the release v4.00/04 but it does not help.[/quote]Too bad.

[quote=“rouby”]Moreover, it seems that the situation is worst, as I can not recover the xterm after root’s crash.[/quote]O, I forgot to submit that as a bug report. I’ve seen that, too, also under linux - seems like a recent change with the keybord handler broke the term input after cint recovery. Try to kill the root pid (in another terminal: use ps to find root’s pid, type "kill " and the pid), then root should be gone, but you still can’t see what you’re typing, right? Then type (into the blind) “reset” and things should be back to normal. Could you confirm that this also works for you, please?

[quote=“rouby”]But the symptoms/behaviour are the same in every other details.[/quote]Okay, I’ll try to reproduce your issues. I’ll let you know when I have something; won’t happen before the end of the week, though.

Axel.

hi Axel,
I confirm the ‘blind behaviour’ of the xterm and that ‘Reset’ works fine for recovering it.
Xavier

This problem should be fixed in the CVS repository (as of May 12).

Cheers,
Philippe.

I tried the brand new Development Version 4.00/06a but it does not help, save for the ‘blind’ behaviour, which has disappeared. But for the rest, nothing changed…

I hope getting good news from you about Root and Cygwin/gcc 3.3 !
Cheers,
Xavier

Hi Xavier,
sorry, totally forgot about that. I’m checking with cvs root from today (pretty close to 4.00/06a).

The binaries are built with gcc 3.2, not 3.3.1 - which probably means your own libs (built with the gcc you have) are incompatible with root’s libs. The only way out is to build root from sources. Rene will update his build environment to a newer gcc only after the pro release in July.

I’d like to know what your problems were; that’s the only way to get it fixed. I know of no current problems with the build process other than running parallel builds, i.e. make -j2, which simply does not work.

But this is not a real problem for me, as I can still compile my scripts.

I.2) and if I recompile the script without changing it, ACLIC says :

[quote]Warning in : unmodified script has already been compiled and loaded
Warning in : it will be regenerated and reloaded!

:17:1: warning: “GNUC_MINOR” redefined

g++: /cygdrive/d/documents/these/beamsim/./bernie_c.dll: No such file or directory
Error in : Compilation failed!
[/quote]
[/quote]
Could you send me a macro that triggers this behavior? The most complex macro I have does not show either of these problems.

I agree, it’s probably due to incompatible libs (root’s built with gcc3.2 and bernie_C.dll with 3.3.1). Try building root from sources, and all your problems should be gone. Have another look at the win32gcc build web page; I had to update the build instructions again (ruby and xml need to be disabled for now).

(edited 2004-06-11: ruby and xml are back in.)

Axel.

Hello Axel,

I tried to compile the sources I just got from CVS (on the June, 21rst). I tried twice, having also a look on your web site. Each times, it fails at the same level. After about 30-40 minutes and long output, I have lots of errors. I attached the output of “make” (I run “./configure win32gcc” and then “make”).

For me, even the smallest program triggers such a behavior : void mine() { }

Do you have any idea ?
Thanks a lot,
Xavier
output.txt (545 KB)

Hi Xavier,
you forgot to install the xorg-x11-devel package (ake sure you also have the xorg-x11-base, xorg-x11-bin, xorg-x11-bin-dlls, xorg-x11-etc, xorg-x11-fenc, xorg-x11-fnts, xorg-x11-fsrv, xorg-x11-libs-data, xorg-x11-xwin packages installed). You can install it using the regular cygwin setup.exe install procedure. Didn’t configure complain about missing x11 headers? Anyway - just re-run make after you installed these packages.

I’ll mention the problem & solution on the web site.
Axel.

Hi Axel, you were right about xorg-x11-devel.

I am now stuck further with make. See the attached file, where you’ll also find the output from “./configure win32gcc”.

Thanks a lot for your help !
compilation_2.txt (4.7 KB)

Hi,
two problems:

  • missing iconv.h: you didn’t install the cygwin package libiconv and libiconv2 (under “libraries”, I believe). You need both, as far as I know - at least libiconv2 is a prerequisite. I should really come up with a complete list of packages that are needed :-]
  • -pthread switch: it’s only a warning, and not harmful. I’ve never seen it; I’ll investigate and let you know when it’s fixed.

Axel.

Hello Axel,

At the end, the compilation process has completed successfully (for the Development Version 4.00/06a). The warnings ("… GNUC_MINOR …") have now disappeared when compiling with ACLIC and also the segmentation violation when doing “mycanvas->Divide(2,1)”.

But I also noticed the know problem “ldd: not found”.

If it can help one, I attached a non-exhaustive list of cygwin packages that I installed before being able to compile ROOT without problem. By the way, how did you guess which packages were missing ?

Thanks a lot for all your help !
Xavier
cygwin_packages.txt (509 Bytes)

Good.

Thanks, that’s a first step…

Because I’ve seen your build errors before. You can use e.g. http://cygwin.com/packages/ to find the package belonging to a missing header.
Axel