Re: [hwloc-devel] === CREATE FAILURE (trunk) ===
Ignore this -- I'm testing the script for the new v1.4 branch and autotools versions; I hit ctrl-c for this run... On Jan 17, 2012, at 4:13 PM, MPI Team wrote: > > ERROR: Command returned a non-zero exist status (trunk): > ./autogen.sh > > Start time: Tue Jan 17 16:13:49 EST 2012 > End time: Tue Jan 17 16:13:55 EST 2012 > > === > autoreconf: Entering directory `.' > autoreconf: configure.ac: not using Gettext > autoreconf: running: aclocal --force -I ./config > autom4te: /u/mpiteam/local/autotools-2.68-1.11.1-2.4-1.4.15/bin/m4 terminated > by signal: 2 > autoreconf: aclocal terminated by signal: 2 > === > > Your friendly daemon, > Cyrador > ___ > hwloc-devel mailing list > hwloc-de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [hwloc-devel] === CREATE FAILURE (trunk) ===
Le 29/08/2011 13:55, Jeff Squyres a écrit : > On Aug 28, 2011, at 9:01 PM, MPI Team wrote: > >> ! LaTeX Error: File `utf8.def' not found. > Crud. Maybe this is why I kept the doxygen back at an older version on > eddie...? > > Any idea how to work past this error? Latex is mysterious in its > installation ways -- can one install utf8.def outside the system latex > install, and set an environment variable (or something) to point to it? Try: TEXINPUTS=/foo/bar:: (adds /foo/bar to the default package search paths) Brice
Re: [hwloc-devel] === CREATE FAILURE (trunk) ===
On Aug 28, 2011, at 9:01 PM, MPI Team wrote: > ! LaTeX Error: File `utf8.def' not found. Crud. Maybe this is why I kept the doxygen back at an older version on eddie...? Any idea how to work past this error? Latex is mysterious in its installation ways -- can one install utf8.def outside the system latex install, and set an environment variable (or something) to point to it? -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [hwloc-devel] === CREATE FAILURE (trunk) ===
On Apr 7, 2011, at 9:01 AM, Brice Goglin wrote: > I don't want to care about RHEL4 unless I have access to such machine :) :-) Let's see if we can get you access to the IU machines. And/or ask them why they're still at RHEL4. > Actually, once the trunk passes make distcheck, it should be easy to > continue supporting RHEL4 until we add another low-level feature that > RHEL4 likely does not support. Ok, "make check" passes now (r3402). > When make distcheck fails, it would be good to get more feeback. Can we > at least place the whole (non-truncated) stderr+stdout on the web ? Sure, let me see what I can do. -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [hwloc-devel] === CREATE FAILURE (trunk) ===
Le 07/04/2011 14:36, Jeff Squyres a écrit : > Do we not care about rhel4 any more? > > I can ask IU what the possibility is of getting a RHEL5 or RHEL6 build > machine. I don't know if it's a low or high probability. > I don't want to care about RHEL4 unless I have access to such machine :) Actually, once the trunk passes make distcheck, it should be easy to continue supporting RHEL4 until we add another low-level feature that RHEL4 likely does not support. When make distcheck fails, it would be good to get more feeback. Can we at least place the whole (non-truncated) stderr+stdout on the web ? The crash should be fixed in current trunk, thanks for the backtrace! Brice
Re: [hwloc-devel] === CREATE FAILURE (trunk) ===
Do we not care about rhel4 any more?
I can ask IU what the possibility is of getting a RHEL5 or RHEL6 build machine.
I don't know if it's a low or high probability.
On Apr 7, 2011, at 2:12 AM, Brice Goglin wrote:
> Le 07/04/2011 03:03, MPI Team a écrit :
>> /bin/sh: line 1: 20599 Segmentation fault ${dir}$tst
>> FAIL: hwloc_iodevs
>>
>
> I don't know about this one, I can't reproduce it anywhere.
>
>> /bin/sh: line 1: 20646 Segmentation fault ${dir}$tst
>> FAIL: xmlbuffer
>>
>
> This one should may be fixed in trunk.
>
> I am tired of getting these undebuggable reports from this crappy RHEL4.
>
> Brice
>
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [hwloc-devel] === CREATE FAILURE (trunk) ===
Le 07/04/2011 03:03, MPI Team a écrit :
> /bin/sh: line 1: 20599 Segmentation fault ${dir}$tst
> FAIL: hwloc_iodevs
>
I don't know about this one, I can't reproduce it anywhere.
> /bin/sh: line 1: 20646 Segmentation fault ${dir}$tst
> FAIL: xmlbuffer
>
This one should may be fixed in trunk.
I am tired of getting these undebuggable reports from this crappy RHEL4.
Brice
Re: [hwloc-devel] === CREATE FAILURE (trunk) ===
This was a "make dist" that was endlessly spinning in hwloc-bind. The IU
admins advised me of it this morning, so I killed the errant hwloc-bind (which
then ended up killing the "make dist", etc.).
On Nov 29, 2010, at 8:51 AM, MPI Team wrote:
>
> ERROR: Command returned a non-zero exist status (trunk):
> make distcheck
>
> Start time: Thu Nov 11 21:01:02 EST 2010
> End time: Mon Nov 29 08:51:33 EST 2010
>
> ===
> [... previous lines snipped ...]
> truncating system cpuset to 51 chars (truncate to four and a half 32bit
> subsets)
> got 0x,0x,0x,0x,0x
> first cpu cpuset is 0x0001
> first cpu cpuset converted back and forth, ok
> last cpu cpuset is 0x8000,,0x0
> last cpu cpuset converted back and forth, ok
> PASS: hwloc_bitmap_string
> looked for 120 closest entries, found 119
> ancestor type 1 depth 0 number 0 is system level
> PASS: hwloc_get_closest_objs
> found covering object type Socket covering cpuset 0x0,0x0fff,0xf000
> covering object of 0x0,0x0fff,0xf000 is 0x,0xff00, expected
> 0x,0xff00
> found system as covering object of first+last cpus cpuset
> 0x8000,,0x1
> found no covering object for too-large cpuset 0x1,,0x0
> PASS: hwloc_get_obj_covering_cpuset
> PASS: hwloc_get_cache_covering_cpuset
> PASS: hwloc_get_largest_objs_inside_cpuset
> PASS: hwloc_get_next_obj_covering_cpuset
> PASS: hwloc_get_obj_inside_cpuset
> PASS: hwloc_get_shared_cache_covering_obj
> PASS: hwloc_get_obj_below_array_by_type
> PASS: hwloc_bitmap_first_last_weight
> PASS: hwloc_bitmap_singlify
> PASS: hwloc_type_depth
> /bin/sh: line 1: 26503 Terminated ${dir}$tst
> FAIL: hwloc_bind
> PASS: hwloc_object_userdata
> PASS: hwloc_synthetic
> Binding with OS backend : OK
> Binding with synthetic backend: OK
> Binding with synthetic backend faking is_thissystem: OK
> PASS: hwloc_is_thissystem
> PASS: hwloc_insert_misc
> PASS: glibc-sched
> exported to buffer 0x9f55750 length 2023
> re-exported to buffer 0x9f5a440 length 2023
> PASS: xmlbuffer
>
> 1 of 19 tests failed
> Please report to http://www.open-mpi.org/community/help/
>
> make[4]: *** [check-TESTS] Error 1
> make[4]: Leaving directory
> `/home/mpiteam/hwloc/nightly-tarball-build-root/trunk/create-r2781/hwloc/hwloc-1.2a1r2781/_build/tests'
> make[3]: *** [check-am] Error 2
> make[3]: Leaving directory
> `/home/mpiteam/hwloc/nightly-tarball-build-root/trunk/create-r2781/hwloc/hwloc-1.2a1r2781/_build/tests'
> make[2]: *** [check-recursive] Error 1
> make[2]: Leaving directory
> `/home/mpiteam/hwloc/nightly-tarball-build-root/trunk/create-r2781/hwloc/hwloc-1.2a1r2781/_build/tests'
> make[1]: *** [check-recursive] Error 1
> make[1]: Leaving directory
> `/home/mpiteam/hwloc/nightly-tarball-build-root/trunk/create-r2781/hwloc/hwloc-1.2a1r2781/_build'
> make: *** [distcheck] Error 1
> ===
>
> Your friendly daemon,
> Cyrador
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [hwloc-devel] === CREATE FAILURE (trunk) ===
It's a RHEL4 system. Ancient.
On Jul 16, 2010, at 9:38 AM, Brice Goglin wrote:
> I guess you have an old glibc there ? and HAVE_OPENAT isn't defined in
> config.h ? I am fixing this.
>
> Brice
>
>
>
> Le 16/07/2010 15:34, Jeff Squyres a écrit :
> > (gdb) bt
> > #0 0x0060bcb8 in strcmp () from /lib/tls/libc.so.6
> > #1 0x00498d7d in hwloc_look_linux (topology=0x8807008)
> > at topology-linux.c:1805
> > #2 0x0048dd9c in hwloc_discover (topology=0x8807008) at topology.c:1423
> > #3 0x0048ed8e in hwloc_topology_load (topology=0x8807008) at
> > topology.c:2005
> > #4 0x080489a4 in main () at hwloc_is_thissystem.c:34
> > (gdb) up
> > #1 0x00498d7d in hwloc_look_linux (topology=0x8807008)
> > at topology-linux.c:1805
> > 1805if (!strcmp(topology->backend_params.sysfs.root_path, "/"))
> > (gdb) p topology->backend_params.sysfs
> > $1 = {root_path = 0x0, root_fd = -1}
> > (gdb)
> >
> > Need any other info?
> >
> >
> > On Jul 16, 2010, at 12:59 AM, Brice Goglin wrote:
> >
> >
> >> Le 16/07/2010 03:02, MPI Team a écrit :
> >>
> >>> /bin/sh: line 1: 1024 Segmentation fault ${dir}$tst
> >>> FAIL: hwloc_bind
> >>> /bin/sh: line 1: 1048 Segmentation fault ${dir}$tst
> >>> FAIL: hwloc_object_userdata
> >>> PASS: hwloc_synthetic
> >>> /bin/sh: line 1: 1094 Segmentation fault ${dir}$tst
> >>> FAIL: hwloc_is_thissystem
> >>> /bin/sh: line 1: 1118 Segmentation fault ${dir}$tst
> >>> FAIL: hwloc_insert_misc
> >>> /bin/sh: line 1: 1142 Segmentation fault ${dir}$tst
> >>> FAIL: glibc-sched
> >>>
> >>>
> >> I can't reproduce this on my machines. Can somebody send the
> >> corresponding gdb backtrace? Take trunk, ./configure, make, make check,
> >> and it fails
> >>libtool --mode=execute gdb
> >>
> >> thanks
> >> Brice
> >>
> >> ___
> >> hwloc-devel mailing list
> >> hwloc-de...@open-mpi.org
> >> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
> >>
> >>
> >
> >
>
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
>
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [hwloc-devel] === CREATE FAILURE (trunk) ===
I guess you have an old glibc there ? and HAVE_OPENAT isn't defined in
config.h ? I am fixing this.
Brice
Le 16/07/2010 15:34, Jeff Squyres a écrit :
> (gdb) bt
> #0 0x0060bcb8 in strcmp () from /lib/tls/libc.so.6
> #1 0x00498d7d in hwloc_look_linux (topology=0x8807008)
> at topology-linux.c:1805
> #2 0x0048dd9c in hwloc_discover (topology=0x8807008) at topology.c:1423
> #3 0x0048ed8e in hwloc_topology_load (topology=0x8807008) at topology.c:2005
> #4 0x080489a4 in main () at hwloc_is_thissystem.c:34
> (gdb) up
> #1 0x00498d7d in hwloc_look_linux (topology=0x8807008)
> at topology-linux.c:1805
> 1805if (!strcmp(topology->backend_params.sysfs.root_path, "/"))
> (gdb) p topology->backend_params.sysfs
> $1 = {root_path = 0x0, root_fd = -1}
> (gdb)
>
> Need any other info?
>
>
> On Jul 16, 2010, at 12:59 AM, Brice Goglin wrote:
>
>
>> Le 16/07/2010 03:02, MPI Team a écrit :
>>
>>> /bin/sh: line 1: 1024 Segmentation fault ${dir}$tst
>>> FAIL: hwloc_bind
>>> /bin/sh: line 1: 1048 Segmentation fault ${dir}$tst
>>> FAIL: hwloc_object_userdata
>>> PASS: hwloc_synthetic
>>> /bin/sh: line 1: 1094 Segmentation fault ${dir}$tst
>>> FAIL: hwloc_is_thissystem
>>> /bin/sh: line 1: 1118 Segmentation fault ${dir}$tst
>>> FAIL: hwloc_insert_misc
>>> /bin/sh: line 1: 1142 Segmentation fault ${dir}$tst
>>> FAIL: glibc-sched
>>>
>>>
>> I can't reproduce this on my machines. Can somebody send the
>> corresponding gdb backtrace? Take trunk, ./configure, make, make check,
>> and it fails
>>libtool --mode=execute gdb
>>
>> thanks
>> Brice
>>
>> ___
>> hwloc-devel mailing list
>> hwloc-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
>>
>>
>
>
Re: [hwloc-devel] === CREATE FAILURE (trunk) ===
On Jul 16, 2010, at 9:34 AM, Jeff Squyres wrote:
> (gdb) bt
> #0 0x0060bcb8 in strcmp () from /lib/tls/libc.so.6
> #1 0x00498d7d in hwloc_look_linux (topology=0x8807008)
>at topology-linux.c:1805
> #2 0x0048dd9c in hwloc_discover (topology=0x8807008) at topology.c:1423
> #3 0x0048ed8e in hwloc_topology_load (topology=0x8807008) at topology.c:2005
> #4 0x080489a4 in main () at hwloc_is_thissystem.c:34
> (gdb) up
> #1 0x00498d7d in hwloc_look_linux (topology=0x8807008)
>at topology-linux.c:1805
> 1805if (!strcmp(topology->backend_params.sysfs.root_path, "/"))
> (gdb) p topology->backend_params.sysfs
> $1 = {root_path = 0x0, root_fd = -1}
> (gdb)
>
> Need any other info?
BTW, I get the same result even if I just run utils/lstopo.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [hwloc-devel] === CREATE FAILURE (trunk) ===
(gdb) bt
#0 0x0060bcb8 in strcmp () from /lib/tls/libc.so.6
#1 0x00498d7d in hwloc_look_linux (topology=0x8807008)
at topology-linux.c:1805
#2 0x0048dd9c in hwloc_discover (topology=0x8807008) at topology.c:1423
#3 0x0048ed8e in hwloc_topology_load (topology=0x8807008) at topology.c:2005
#4 0x080489a4 in main () at hwloc_is_thissystem.c:34
(gdb) up
#1 0x00498d7d in hwloc_look_linux (topology=0x8807008)
at topology-linux.c:1805
1805 if (!strcmp(topology->backend_params.sysfs.root_path, "/"))
(gdb) p topology->backend_params.sysfs
$1 = {root_path = 0x0, root_fd = -1}
(gdb)
Need any other info?
On Jul 16, 2010, at 12:59 AM, Brice Goglin wrote:
> Le 16/07/2010 03:02, MPI Team a écrit :
> > /bin/sh: line 1: 1024 Segmentation fault ${dir}$tst
> > FAIL: hwloc_bind
> > /bin/sh: line 1: 1048 Segmentation fault ${dir}$tst
> > FAIL: hwloc_object_userdata
> > PASS: hwloc_synthetic
> > /bin/sh: line 1: 1094 Segmentation fault ${dir}$tst
> > FAIL: hwloc_is_thissystem
> > /bin/sh: line 1: 1118 Segmentation fault ${dir}$tst
> > FAIL: hwloc_insert_misc
> > /bin/sh: line 1: 1142 Segmentation fault ${dir}$tst
> > FAIL: glibc-sched
> >
>
> I can't reproduce this on my machines. Can somebody send the
> corresponding gdb backtrace? Take trunk, ./configure, make, make check,
> and it fails
>libtool --mode=execute gdb
>
> thanks
> Brice
>
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
>
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [hwloc-devel] === CREATE FAILURE (trunk) ===
Le 16/07/2010 03:02, MPI Team a écrit :
> /bin/sh: line 1: 1024 Segmentation fault ${dir}$tst
> FAIL: hwloc_bind
> /bin/sh: line 1: 1048 Segmentation fault ${dir}$tst
> FAIL: hwloc_object_userdata
> PASS: hwloc_synthetic
> /bin/sh: line 1: 1094 Segmentation fault ${dir}$tst
> FAIL: hwloc_is_thissystem
> /bin/sh: line 1: 1118 Segmentation fault ${dir}$tst
> FAIL: hwloc_insert_misc
> /bin/sh: line 1: 1142 Segmentation fault ${dir}$tst
> FAIL: glibc-sched
>
I can't reproduce this on my machines. Can somebody send the
corresponding gdb backtrace? Take trunk, ./configure, make, make check,
and it fails
libtool --mode=execute gdb
thanks
Brice
Re: [hwloc-devel] === CREATE FAILURE (trunk) ===
It was using the wrong autotools (older stuff). I just fixed it and re-ran -- let's see if it works now. On Nov 3, 2009, at 9:09 PM, Samuel Thibault wrote: MPI Team, le Tue 03 Nov 2009 21:01:23 -0500, a écrit : > ERROR: Command returned a non-zero exist status (trunk): >./autogen.sh Ah, sorry, it is. Mmmm how is it running > autoreconf: running: aclocal --force -I config while autoreconf was passed -I m4? I've just tried from a fresh checkout and didn't have the problem. Samuel ___ hwloc-devel mailing list hwloc-de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel -- Jeff Squyres jsquy...@cisco.com
Re: [hwloc-devel] === CREATE FAILURE (trunk) ===
MPI Team, le Tue 03 Nov 2009 21:01:23 -0500, a écrit : > ERROR: Command returned a non-zero exist status (trunk): >./autogen.sh Ah, sorry, it is. Mmmm how is it running > autoreconf: running: aclocal --force -I config while autoreconf was passed -I m4? I've just tried from a fresh checkout and didn't have the problem. Samuel
Re: [hwloc-devel] === CREATE FAILURE (trunk) ===
MPI Team, le Tue 03 Nov 2009 21:01:23 -0500, a écrit : > autoreconf: running: aclocal --force -I config Mmm, the bot should be made to use ./autogen.sh instead. Samuel
