Build of root_v5.24.00 fails on linux/alpha: error: conflict

Hi all,

As noted in the subject, build of root_v5.24.00 fails on linux/alpha:

... gcc -pipe -Wall -fPIC -DG__REGEXP -DG__UNIX -DG__SHAREDLIB -DG__OSFDLL -DG__ROOT -DG__REDIRECTIO -DG__64BIT -DG__HAVE_CONFIG -DG__NOMAKEINFO -Icint/cint/inc -Icint/cint/src -Icint/cint/src/dict -I. -DG__SYSTYPES_H -I. -Icint/cint/inc -o cint/cint/lib/G__c_posix.o -c cint/cint/lib/G__c_posix.c In file included from ./cint/cint/lib/posix/exten.h:16, from ./cint/cint/lib/G__c_posix.h:26, from cint/cint/lib/G__c_posix.c:4: ./cint/cint/lib/posix/posix.h:287: error: conflicting types for ‘setpgrp’ /usr/include/unistd.h:617: error: previous declaration of ‘setpgrp’ was here make: *** [cint/cint/lib/G__c_posix.o] Error 1 rm core/utils/src/RStl_tmp.cxx core/utils/src/rootcint_tmp.cxx

I’ve tried on two alpha machines with almost the same spec (164LX 533MHz) but running different distro., Gentoo 2008.0 and Debian 5.0.3, and the build fails at the same place shown above.

Gentoo:
[ul]Configured as ./configure -> ‘linuxalphagcc’ was selected
Linux genalpha 2.6.30-gentoo-r6 #1 SMP Sun Sep 20 15:48:20 JST 2009 alpha EV56 EB164 GNU/Linux

  • sys-libs/glibc: 2.9_p20081201-r3
    gcc (Gentoo 4.3.2-r3 p1.6, pie-10.1.5) 4.3.2[/ul]

Debian:
[ul]Configured as ./configure linuxalphagcc
Linux debalpha 2.6.26-2-alpha-generic #1 Wed Aug 19 22:14:00 UTC 2009 alpha GNU/Linux
glibc-2.7-1
gcc (GCC) 4.2.4 (Debian 4.2.4-6)[/ul]

./cint/cint/lib/posix/posix.h:287

286 #elif defined(G__FBSD)||defined(__FreeBSD__)||defined(G__OBSD)||defined(__OpenBSD__ 286 )||((defined(G__alpha)||defined(__alpha))&&(defined(G__GNUC) || defined(G__LINUX) | 286 | defined(__linux__)))||((defined(G__alpha)||defined(__alpha))&&defined(G__GNUC)) 287 extern int setpgrp(pid_t _pid, pid_t _pgrp); 288 #elif defined(G__KCC) || defined(__KCC)

/usr/include/unistd.h:617

597 /* Set the process group ID of the process matching PID to PGID. 598 If PID is zero, the current process's process group ID is set. 599 If PGID is zero, the process ID of the process is used. */ 600 extern int setpgid (__pid_t __pid, __pid_t __pgid) __THROW; 601 602 #if defined __USE_SVID || defined __USE_BSD || defined __USE_XOPEN_EXTENDED 603 /* Both System V and BSD have `setpgrp' functions, but with different 604 calling conventions. The BSD function is the same as POSIX.1 `setpgid' 605 (above). The System V function takes no arguments and puts the calling 606 process in its on group like `setpgid (0, 0)'. 607 608 New programs should always use `setpgid' instead. 609 610 The default in GNU is to provide the System V function. The BSD 611 function is available under -D_BSD_SOURCE. */ 612 613 # ifndef __FAVOR_BSD 614 615 /* Set the process group ID of the calling process to its own PID. 616 This is exactly the same as `setpgid (0, 0)'. */ 617 extern int setpgrp (void) __THROW; 618 619 # else 620 621 /* Another name for `setpgid' (above). */ 622 # ifdef __REDIRECT_NTH 623 extern int __REDIRECT_NTH (setpgrp, (__pid_t __pid, __pid_t __pgrp), setpgid); 624 # else 625 # define setpgrp setpgid 626 # endif 627 628 # endif /* Favor BSD. */ 629 #endif /* Use SVID or BSD. */

Any clue?

Thanks in advance…

Yours,
Kazuyoshi

Hi Kazuyoshi,

already since several years we don’t anymore have access to an Alpha machine, hence it is very likely some things are broken. The only way to get this fixed is for you to make the fixes and to mail us the patches. The setpgrp should not be too difficult. Just try to adjust the #ifdef to the right case for your machine and once it works let us know.

Cheers, Fons.

Hi,

Ah, it’s not difficult to imagine that…

Anyway, with the attached patch with the following configure option,

linuxalphagcc --disable-xrootd

root v5.24.00 can be built; it actually runs, demoshelp.C can be run, TBrowser works well (though I’m not sure these modifications are correct or not).

demos.C failed to run, displaying the following message:

root [0] .x demos.C Limitation: Variable argument is not supported for this platform demos.C:13: *** Interpreter error recovered ***
I’ll try to fix this later.

To build root with xrootd enabled, further modification is in need: at present it is configured as i386_linux and with -m32 even on Alphas, and I’m trying to modify its Module.mk…

Kazuyoshi

p.s. needless to say, compared to the recent machines, more-than-a-decade-old 533-MHz Alpha is too slow to compile and run root…

p.s.2 it may then be better to move to another forum…
alpha-without-xrootd-against-v5.24.00.diff.gz (965 Bytes)

[quote=“furutaka”]To build root with xrootd enabled, further modification is in need: at present it is configured as i386_linux and with -m32 even on Alphas, and I’m trying to modify its Module.mk
[/quote]

With the following modification to net/xroot/Module.mk, linuxalphagcc can be detected:

[code]— Module.mk.orig 2009-06-30 16:23:14.000000000 +0900
+++ Module.mk 2009-09-28 22:08:01.000000000 +0900
@@ -109,6 +109,7 @@
linuxx8664gcc:) xopt="–ccflavour=gccx8664 --use-xrd-strlcpy";;
linuxx8664icc:
) xopt="–ccflavour=iccx8664 --use-xrd-strlcpy";;
linuxppc64gcc:*) xopt="–ccflavour=gccppc64 --use-xrd-strlcpy";; \

  •   linuxalphagcc:*) xopt="--ccflavour=gcc --use-xrd-strlcpy";; \
      linux*:*)        xarch="i386_linux"; xopt="--ccflavour=gcc --use-xrd-strlcpy";; \
      macosx64:*)      xopt="--ccflavour=macos64";; \
      macosxicc:*)     xopt="--ccflavour=icc";; \
    

[/code]

However, xrootd is still configured with “-m32”. It seems to me that it’s because the option is used in TYPEMISC and TYPELDSO of net/xrootd/src/xrootd/config/GNUmake.rules.gcc for all the following architecture even if it’s not a 32-bit one:

[furutaka@Furutaka-1 xrootd]$ awk '$2=="gcc"{print}' src/xrootd/config/ARCHS FreeBSD5 gcc no for FreeBSD 5.x FreeBSD42 gcc no for FreeBSD 4.2 FreeBSD43 gcc no for FreeBSD 4.3 FreeBSD44 gcc no for FreeBSD 4.4 FreeBSD4 gcc no for FreeBSD 4.x FreeBSD gcc no for FreeBSD arm_linux gcc all for ARM Linux kernel 2.x.y gcc and glibc i386_linux22 gcc all for Linux kernel 2.2.x gcc and glibc i386_linux24 gcc all for Linux kernel 2.4.x gcc and glibc i386_linux26 gcc all for Linux kernel 2.6.x gcc and glibc i386_linux gcc all for Linux gcc and glibc i386_rhel30 gcc all for Linux kernel 2.4.x Enterprise Release i386_linux gcc all for AMD Athlon Linux gcc glibc alpha_linux gcc all for Alpha Linux egcs and glibc sparc_linux gcc all for Sparc Linux gcc and glibc mips_linux gcc all for GNU/Linux on MIPS - 32bit, big endian hppa_linux gcc all for GNU/Linux on HP/PA - 32bit, big endian arm_linux gcc no for ARM Linux egcs and glibc ppc_linux gcc all for PPC Linux egcs/gcc and glibc sgi gcc no for SGI IRIX 6.x with gcc and glibc

Are there any easy and effective ways to add the “-m32” option if and only if it’s appropriate to do so? (to use one of the make variables such as ARCH or xarch???)

Kazuyoshi

I’m testing whether the following modification to the net/xrootd/src/xrootd/config/GNUmake.rules.gcc works or not, on a 32-bit linux machine.

[code]— GNUmake.rules.gcc.orig 2009-06-30 16:23:14.000000000 +0900
+++ GNUmake.rules.gcc 2009-09-30 08:54:13.561981951 +0900
@@ -7,13 +7,17 @@
TYPECC = g++
TYPELD = g++

-TYPEMISC = -m32 -D_ALL_SOURCE -D_REENTRANT -D_GNU_SOURCE -fPIC -rdynamic
+TYPEMISC = -D_ALL_SOURCE -D_REENTRANT -D_GNU_SOURCE -fPIC -rdynamic
-Wall -Wno-deprecated -D__linux__ (CFTRACE) TYPECF32 = TYPECF64 = -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 TYPEOPT = (TYPEMISC) -O2
TYPEDBG = (TYPEMISC) -g -TYPELDSO = -m32 -shared +TYPELDSO = -shared TYPESHLIB = so +ifneq (,(findstring i386,$(ARCH)))
+TYPEMISC += -m32
+TYPELDSO += -m32
+endif

TYPELIBS = -lnsl $(PTHREAD) -lrt -ldl -lc
[/code]

Kazuyoshi

Hi,

The attached is the cumulative patch to build v5.24.00(not v5.25.02) on/with recent linux/alpha/gcc with xrootd enabled. With this, I have succeeded (though I’m not sure whether it’s correct to modify in this way or not…) in building root (taking one night on a 533-MHz LX164) on the latest Debian stable (see the first post) with the following topmost configure option:

linuxalphagcc

The configure process enabled the support of the following:

Enabled support for asimage, astiff, builtin_afterimage, builtin_ftgl, builtin_freetype, builtin_pcre, builtin_zlib, cint5, cintex, exceptions, genvector, krb5, ldap, mathmore, memstat, opengl, python, reflex, shadowpw, shared, ssl, xft, xml, xrootd. At home I’m trying to build it with ruby, minuit2, gdml, and roofit enabled.

I made sure that even with the attached patch xrootd is build with the appropriate options ("-m32"/"-m64") on the latest Fedora 11 (x86_64), Gentoo 2008.0 (i386), and Debian 5.0.3 (i386).

[quote=“furutaka”]demos.C failed to run, displaying the following message:

root [0] .x demos.C Limitation: Variable argument is not supported for this platform demos.C:13: *** Interpreter error recovered ***
I’ll try to fix this later.[/quote]

If I understand correctly, to break the above limitation one needs to add appropriate entries to define variables such as G__VAARG_INC_COPY_N and G__VAARG_PASS_BY_REFERENCE, to cint/cint/inc/G__ci.h and cint/cint7/src/vararg.h. I do not know how to do it. Could some kind souls help me do it?

Kazuyoshi
alpha-with-xrootd-against-v5.24.00.diff.gz (1.45 KB)

Hi Kazuyoshi,

I am currently traveling but as soon as I am back, I will merge your diffs in the trunk. Thanks for the work.

Cheers, Fons.

Hi Fons,

So here’s the one against the latest dev release, v5.25.02. It became simpler because of the introduction of SUPPORTS_MEMSTAT in misc/memsta/src/TMemStatDepend.cxx.

Yours,
Kazuyoshi
alpha-with-xrootd-against-v5.25.02.diff.gz (1.05 KB)

Hi,

By the way, I experienced an issue when building v5.25/02 with --enable-cint7 with the patch I attached to the previous post;

cp cint/iosenum/iosenum.linuxalphagcc3 cint/cint7/include/iosenum.h cint/cint7//main/cint_tmp \ -w1 -zvector -ncint/cint7/lib/dll_stl/G__cpp_vector.cxx \ -D__MAKECINT__ -DG__MAKECINT \ -Icint/cint7/lib/dll_stl -Icint/cint7/lib \ -c-1 -A -Z0 cint/cint7/lib/dll_stl/vec.h cint/cint7/inc/cintdictversion.h make: *** [cint/cint7/lib/dll_stl/G__cpp_vector.cxx] Illegal instruction rm core/utils/src/RStl_tmp.cxx core/utils/src/RStl7_tmp.cxx core/utils/src/rootcint7_tmp.cxx core/utils/src/rootcint_tmp.cxx

I saw this issue only on my Debian/alpha machine (LX164 533MHz); on another alpha machine (also LX164 533MHz) which runs Gentoo/alpha machine, it was successfully built with (almost all) the same options.

I feel it’s difficult to resolve this issue because after adding the --build=debug option the build with --enable-cint7 became successful… :confused:

Kazuyoshi

[quote=“furutaka”]cp cint/iosenum/iosenum.linuxalphagcc3 cint/cint7/include/iosenum.h cint/cint7//main/cint_tmp \ -w1 -zvector -ncint/cint7/lib/dll_stl/G__cpp_vector.cxx \ -D__MAKECINT__ -DG__MAKECINT \ -Icint/cint7/lib/dll_stl -Icint/cint7/lib \ -c-1 -A -Z0 cint/cint7/lib/dll_stl/vec.h cint/cint7/inc/cintdictversion.h make: *** [cint/cint7/lib/dll_stl/G__cpp_vector.cxx] Illegal instruction rm core/utils/src/RStl_tmp.cxx core/utils/src/RStl7_tmp.cxx core/utils/src/rootcint7_tmp.cxx core/utils/src/rootcint_tmp.cxx[/quote]

The backtrace obtained with gdb is as follows:

[code]furutaka@debalpha:~/work/root/root_v5.25.02.withCint7noDbg$ gdb ./cint/cint7//main/cint_tmp
GNU gdb 6.8-debian
Copyright © 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and “show warranty” for details.
This GDB was configured as “alpha-linux-gnu”…
(gdb) run -w1 -zvector -ncint/cint7/lib/dll_stl/G__cpp_vector.cxx -D__MAKECINT__ -DG__MAKECINT -Icint/cint7/lib/dll_stl -Icint/cint7/lib -c-1 -A -Z0 cint/cint7/lib/dll_stl/vec.h cint/cint7/inc/cintdictversion.h
Starting program: /home/furutaka/work/root/root_v5.25.02.withCint7noDbg/cint/cint7/main/cint_tmp -w1 -zvector -ncint/cint7/lib/dll_stl/G__cpp_vector.cxx -D__MAKECINT__ -DG__MAKECINT -Icint/cint7/lib/dll_stl -Icint/cint7/lib -c-1 -A -Z0 cint/cint7/lib/dll_stl/vec.h cint/cint7/inc/cintdictversion.h

Program received signal SIGILL, Illegal instruction.
0x00000001208dd064 in OperLess::Select<long long, double>::Apply(G__value const*, G__value*)::bool_type ()
(gdb) bt
#0 0x00000001208dd064 in OperLess::Select<long long, double>::Apply(G__value const*, G__value*)::bool_type ()
#1 0x00000001203778fc in Cint::Internal::G__StrBuf::GetReservoir ()
#2 0x00000001203779a8 in Cint::Internal::G__StrBuf::~G__StrBuf ()
#3 0x00000001200f3c50 in Cint::Internal::G__argtype2param ()
#4 0x000000012010c3fc in G__get_methodhandle ()
#5 0x00000001200a591c in Cint::G__ClassInfo::GetMethod ()
#6 0x0000000120130de8 in Cint::G__SetGlobalcomp ()
#7 0x000000012014920c in Cint::Internal::G__specify_link ()
#8 0x0000000120335784 in Cint::Internal::G__pragma ()
#9 0x0000000120176af8 in Cint::Internal::G__exec_statement ()
#10 0x0000000120126ce0 in G__loadfile ()
#11 0x0000000120128168 in Cint::Internal::G__include_file ()
#12 0x000000012017a500 in Cint::Internal::G__exec_statement ()
#13 0x0000000120126ce0 in G__loadfile ()
#14 0x0000000120128168 in Cint::Internal::G__include_file ()
#15 0x000000012017a500 in Cint::Internal::G__exec_statement ()
#16 0x0000000120126ce0 in G__loadfile ()
#17 0x0000000120128168 in Cint::Internal::G__include_file ()
#18 0x000000012017a500 in Cint::Internal::G__exec_statement ()
#19 0x0000000120126ce0 in G__loadfile ()
#20 0x0000000120128168 in Cint::Internal::G__include_file ()
#21 0x000000012017a500 in Cint::Internal::G__exec_statement ()
#22 0x000000012037c44c in Cint::Internal::G__define_struct ()
#23 0x0000000120175254 in Cint::Internal::G__exec_statement ()
#24 0x0000000120126ce0 in G__loadfile ()
#25 0x0000000120128168 in Cint::Internal::G__include_file ()
#26 0x000000012017a500 in Cint::Internal::G__exec_statement ()
#27 0x0000000120126ce0 in G__loadfile ()
#28 0x000000012011db8c in G__main ()
#29 0x0000000120082944 in main ()
(gdb) list
1 /build/buildd/glibc-2.7/build-tree/alpha-libc/csu/crtn.S: No such file or directory.
in /build/buildd/glibc-2.7/build-tree/alpha-libc/csu/crtn.S
[/code]

Kazuyoshi :confused:

Hi,

What’s the latest with this patch?

Kazuyoshi

Hi,

Are you still using linux/alpha? If so could you post an updated patch?

Thanks,
Philippe.

Hi,

I’m very sorry to be late I just found this post when re-reading this thread after failing a gentoo root ebuild (5.26.00-r4).

Yes, I’m still using some linux/alpha machines. I’ll try to make the updated patch. :wink:

Kazuyoshi

With the attached patches (needless to say for 5.26/00 and 5.27/04) I could compile root v5.26/00 and v5.27/04 on linux/alpha

Linux genalpha 2.6.30-gentoo-r6 #1 SMP Sun Sep 20 15:48:20 JST 2009 alpha EV56 EB164 GNU/Linux

Their builds were tested with the following configuration:
5.26/00:

linuxalphagcc --enable-minuit2 --enable-roofit --enable-gdml --enable-cint7 --enable-python --with-python-libdir=/usr/lib --enable-ruby --with-ftgl-libdir=/usr/lib --with-glew-libdir=/usr/lib

5.27/04:

linuxalphagcc --enable-minuit2 --enable-roofit --enable-gdml --enable-python --with-python-libdir=/usr/lib --enable-ruby --with-ftgl-libdir=/usr/lib --with-glew-libdir=/usr/lib

Basic functionality such as TBrowser, hsimple.C, etc. was tested with the latter.

Fons, could you merge (one of) them?

Kazuyoshi
alpha-v5.27.04.diff.gz (1.07 KB)
alpha-v5.26.00.diff.gz (1.02 KB)

I’ll merge the 5.27 one (we’re not updating 5.26 only for essential bug fixing patches).

Cheers, Fons.

I’ve applied the patch to the trunk.

Cheers, Fons.

[quote=“rdm”]I’ve applied the patch to the trunk.

Cheers, Fons.[/quote]

Thanks. :smiley:

Kazuyoshi