- discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] [EXTERNAL] Re: mpiexec error
by Mccall, Kurt E. (MSFC-EV41) 06 May '22

06 May '22

Ken, The node file has 420 lines, with 20 lines for each host, including n022.cluster.com (21 nodes, 20 cores per node) Thanks, Kurt -----Original Message----- From: Raffenetti, Ken <raffenet(a)anl.gov> Sent: Friday, May 6, 2022 12:13 PM To: discuss(a)mpich.org Cc: Mccall, Kurt E. (MSFC-EV41) <kurt.e.mccall(a)nasa.gov> Subject: [EXTERNAL] Re: [mpich-discuss] mpiexec error Hi Kurt, Before running mpiexec, can you print out the hostfile to confirm the contents? Something like this: cat $PBS_HOSTFILE Ken On 5/6/22, 11:55 AM, "Mccall, Kurt E. (MSFC-EV41) via discuss" <discuss(a)mpich.org> wrote: Running MPICH 4.0.1 under Torque 5.1, I’m getting the mpiexec error “user specified host not in the PBS allocated list”. My qsub command is: qsub -V -j oe -e stdio -o stdio -f -X -l nodes=21:ppn=20 <bash_script> My mpiexec command is: mpiexec -print-all-exitcodes -enable-x -np 21 -wdir ${work_dir} -env DISPLAY localhost:10.0 --ppn 1 <more args> … Here is the full error message. Thanks for any help. [mpiexec(a)n022.cluster.com] find_pbs_node_id (../../../../mpich-4.0.1/src/pm/hydra/tools/bootstrap/external/pbs_launch.c:27): user specified host not in the PBS allocated list [mpiexec(a)n022.cluster.com] HYDT_bscd_pbs_launch_procs (../../../../mpich-4.0.1/src/pm/hydra/tools/bootstrap/external/pbs_launch.c:74): error finding PBS node ID for host n022 [mpiexec(a)n022.cluster.com] HYDT_bsci_launch_procs (../../../../mpich-4.0.1/src/pm/hydra/tools/bootstrap/src/bsci_launch.c:17): launcher returned error while launching processes [mpiexec(a)n022.cluster.com] fn_spawn (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmiserv_pmi_v1.c:580): launcher cannot launch processes [mpiexec(a)n022.cluster.com] handle_pmi_cmd (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmiserv_cb.c:48): PMI handler returned error [mpiexec(a)n022.cluster.com] control_cb (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmiserv_cb.c:284): unable to process PMI command [mpiexec(a)n022.cluster.com] HYDT_dmxu_poll_wait_for_event (../../../../mpich-4.0.1/src/pm/hydra/tools/demux/demux_poll.c:76): callback returned error status [mpiexec(a)n022.cluster.com] HYD_pmci_wait_for_completion (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmiserv_pmci.c:160): error waiting for event [mpiexec(a)n022.cluster.com] main (../../../../mpich-4.0.1/src/pm/hydra/ui/mpich/mpiexec.c:325): process manager error waiting for completion [proxy:0:[email protected]] HYD_pmcd_pmip_control_cmd_cb (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmip_cb.c:899): assert (!closed) failed [proxy:0:[email protected]] HYDT_dmxu_poll_wait_for_event (../../../../mpich-4.0.1/src/pm/hydra/tools/demux/[proxy:0:[email protected]] HYD_pmcd_pmip_control_cmd_cb (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmip_cb.c:899): assert (!closed) failed [proxy:0:[email protected]] HYDT_dmxu_poll_wait_for_event (../../../../mpich-4.0.1/src/pm/hydra/tools/demux/[proxy:0:[email protected]] HYD_pmcd_pmip_control_cmd_cb (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmip_cb.c:899): assert (!closed) failed [proxy:0:[email protected]] HYDT_dmxu_poll_wait_for_event (../../../../mpich-4.0.1/src/pm/hydra/tools/demux/[proxy:0:[email protected]] HYD_pmcd_pmip_control_cmd_cb (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmip_cb.c:899): assert (!closed) failed [proxy:0:[email protected]] HYDT_dmxu_poll_wait_for_event (../../../../mpich-4.0.1/src/pm/hydra/tools/demu[proxy:0:[email protected]] HYD_pmcd_pmip_control_cmd_cb (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmip_cb.c:899): assert (!closed) failed [proxy:0:[email protected]] HYDT_dmxu_poll_wait_for_event (../../../../mpich-4.0.1/src/pm/hydra/tools/demu[proxy:0:[email protected]] HYD_pmcd_pmip_control_cmd_cb (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmip_cb.c:899): assert (!closed) failed [proxy:0:[email protected]] HYDT_dmxu_poll_wait_for_event (../../../../mpich-4.0.1/src/pm/hydra/tools/demu[proxy:0:[email protected]] HYD_pmcd_pmip_control_cmd_cb (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmip_cb.c:899): assert (!closed) failed [proxy:0:[email protected]] HYDT_dmxu_poll_wait_for_event (../../../../mpich-4.0.1/src/pm/hydra/tools/demudemux_poll.c:76): callback returned error status [proxy:0:[email protected]] main (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmip.c:169): demux engine error waiting for event demux_poll.c:76): callback returned error status [proxy:0:[email protected]] main (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmip.c:169): demux engine error waiting for event [proxy:0:[email protected]] HYD_pmcd_pmip_control_cmd_cb (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmip_cb.c:899): assert (!closed) failed

1 0

Re: [mpich-discuss] mpiexec error
by Raffenetti, Ken 06 May '22

06 May '22

Hi Kurt, Before running mpiexec, can you print out the hostfile to confirm the contents? Something like this: cat $PBS_HOSTFILE Ken On 5/6/22, 11:55 AM, "Mccall, Kurt E. (MSFC-EV41) via discuss" <discuss(a)mpich.org> wrote: Running MPICH 4.0.1 under Torque 5.1, I’m getting the mpiexec error “user specified host not in the PBS allocated list”. My qsub command is: qsub -V -j oe -e stdio -o stdio -f -X -l nodes=21:ppn=20 <bash_script> My mpiexec command is: mpiexec -print-all-exitcodes -enable-x -np 21 -wdir ${work_dir} -env DISPLAY localhost:10.0 --ppn 1 <more args> … Here is the full error message. Thanks for any help. [mpiexec(a)n022.cluster.com] find_pbs_node_id (../../../../mpich-4.0.1/src/pm/hydra/tools/bootstrap/external/pbs_launch.c:27): user specified host not in the PBS allocated list [mpiexec(a)n022.cluster.com] HYDT_bscd_pbs_launch_procs (../../../../mpich-4.0.1/src/pm/hydra/tools/bootstrap/external/pbs_launch.c:74): error finding PBS node ID for host n022 [mpiexec(a)n022.cluster.com] HYDT_bsci_launch_procs (../../../../mpich-4.0.1/src/pm/hydra/tools/bootstrap/src/bsci_launch.c:17): launcher returned error while launching processes [mpiexec(a)n022.cluster.com] fn_spawn (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmiserv_pmi_v1.c:580): launcher cannot launch processes [mpiexec(a)n022.cluster.com] handle_pmi_cmd (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmiserv_cb.c:48): PMI handler returned error [mpiexec(a)n022.cluster.com] control_cb (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmiserv_cb.c:284): unable to process PMI command [mpiexec(a)n022.cluster.com] HYDT_dmxu_poll_wait_for_event (../../../../mpich-4.0.1/src/pm/hydra/tools/demux/demux_poll.c:76): callback returned error status [mpiexec(a)n022.cluster.com] HYD_pmci_wait_for_completion (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmiserv_pmci.c:160): error waiting for event [mpiexec(a)n022.cluster.com] main (../../../../mpich-4.0.1/src/pm/hydra/ui/mpich/mpiexec.c:325): process manager error waiting for completion [proxy:0:[email protected]] HYD_pmcd_pmip_control_cmd_cb (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmip_cb.c:899): assert (!closed) failed [proxy:0:[email protected]] HYDT_dmxu_poll_wait_for_event (../../../../mpich-4.0.1/src/pm/hydra/tools/demux/[proxy:0:[email protected]] HYD_pmcd_pmip_control_cmd_cb (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmip_cb.c:899): assert (!closed) failed [proxy:0:[email protected]] HYDT_dmxu_poll_wait_for_event (../../../../mpich-4.0.1/src/pm/hydra/tools/demux/[proxy:0:[email protected]] HYD_pmcd_pmip_control_cmd_cb (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmip_cb.c:899): assert (!closed) failed [proxy:0:[email protected]] HYDT_dmxu_poll_wait_for_event (../../../../mpich-4.0.1/src/pm/hydra/tools/demux/[proxy:0:[email protected]] HYD_pmcd_pmip_control_cmd_cb (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmip_cb.c:899): assert (!closed) failed [proxy:0:[email protected]] HYDT_dmxu_poll_wait_for_event (../../../../mpich-4.0.1/src/pm/hydra/tools/demu[proxy:0:[email protected]] HYD_pmcd_pmip_control_cmd_cb (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmip_cb.c:899): assert (!closed) failed [proxy:0:[email protected]] HYDT_dmxu_poll_wait_for_event (../../../../mpich-4.0.1/src/pm/hydra/tools/demu[proxy:0:[email protected]] HYD_pmcd_pmip_control_cmd_cb (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmip_cb.c:899): assert (!closed) failed [proxy:0:[email protected]] HYDT_dmxu_poll_wait_for_event (../../../../mpich-4.0.1/src/pm/hydra/tools/demu[proxy:0:[email protected]] HYD_pmcd_pmip_control_cmd_cb (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmip_cb.c:899): assert (!closed) failed [proxy:0:[email protected]] HYDT_dmxu_poll_wait_for_event (../../../../mpich-4.0.1/src/pm/hydra/tools/demudemux_poll.c:76): callback returned error status [proxy:0:[email protected]] main (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmip.c:169): demux engine error waiting for event demux_poll.c:76): callback returned error status [proxy:0:[email protected]] main (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmip.c:169): demux engine error waiting for event [proxy:0:[email protected]] HYD_pmcd_pmip_control_cmd_cb (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmip_cb.c:899): assert (!closed) failed

1 0

mpiexec error
by Mccall, Kurt E. (MSFC-EV41) 06 May '22

06 May '22

Running MPICH 4.0.1 under Torque 5.1, I'm getting the mpiexec error "user specified host not in the PBS allocated list". My qsub command is: qsub -V -j oe -e stdio -o stdio -f -X -l nodes=21:ppn=20 <bash_script> My mpiexec command is: mpiexec -print-all-exitcodes -enable-x -np 21 -wdir ${work_dir} -env DISPLAY localhost:10.0 --ppn 1 <more args> ... Here is the full error message. Thanks for any help. [mpiexec(a)n022.cluster.com] find_pbs_node_id (../../../../mpich-4.0.1/src/pm/hydra/tools/bootstrap/external/pbs_launch.c:27): user specified host not in the PBS allocated list [mpiexec(a)n022.cluster.com] HYDT_bscd_pbs_launch_procs (../../../../mpich-4.0.1/src/pm/hydra/tools/bootstrap/external/pbs_launch.c:74): error finding PBS node ID for host n022 [mpiexec(a)n022.cluster.com] HYDT_bsci_launch_procs (../../../../mpich-4.0.1/src/pm/hydra/tools/bootstrap/src/bsci_launch.c:17): launcher returned error while launching processes [mpiexec(a)n022.cluster.com] fn_spawn (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmiserv_pmi_v1.c:580): launcher cannot launch processes [mpiexec(a)n022.cluster.com] handle_pmi_cmd (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmiserv_cb.c:48): PMI handler returned error [mpiexec(a)n022.cluster.com] control_cb (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmiserv_cb.c:284): unable to process PMI command [mpiexec(a)n022.cluster.com] HYDT_dmxu_poll_wait_for_event (../../../../mpich-4.0.1/src/pm/hydra/tools/demux/demux_poll.c:76): callback returned error status [mpiexec(a)n022.cluster.com] HYD_pmci_wait_for_completion (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmiserv_pmci.c:160): error waiting for event [mpiexec(a)n022.cluster.com] main (../../../../mpich-4.0.1/src/pm/hydra/ui/mpich/mpiexec.c:325): process manager error waiting for completion [proxy:0:[email protected]] HYD_pmcd_pmip_control_cmd_cb (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmip_cb.c:899): assert (!closed) failed [proxy:0:[email protected]] HYDT_dmxu_poll_wait_for_event (../../../../mpich-4.0.1/src/pm/hydra/tools/demux/[proxy:0:[email protected]] HYD_pmcd_pmip_control_cmd_cb (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmip_cb.c:899): assert (!closed) failed [proxy:0:[email protected]] HYDT_dmxu_poll_wait_for_event (../../../../mpich-4.0.1/src/pm/hydra/tools/demux/[proxy:0:[email protected]] HYD_pmcd_pmip_control_cmd_cb (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmip_cb.c:899): assert (!closed) failed [proxy:0:[email protected]] HYDT_dmxu_poll_wait_for_event (../../../../mpich-4.0.1/src/pm/hydra/tools/demux/[proxy:0:[email protected]] HYD_pmcd_pmip_control_cmd_cb (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmip_cb.c:899): assert (!closed) failed [proxy:0:[email protected]] HYDT_dmxu_poll_wait_for_event (../../../../mpich-4.0.1/src/pm/hydra/tools/demu[proxy:0:[email protected]] HYD_pmcd_pmip_control_cmd_cb (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmip_cb.c:899): assert (!closed) failed [proxy:0:[email protected]] HYDT_dmxu_poll_wait_for_event (../../../../mpich-4.0.1/src/pm/hydra/tools/demu[proxy:0:[email protected]] HYD_pmcd_pmip_control_cmd_cb (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmip_cb.c:899): assert (!closed) failed [proxy:0:[email protected]] HYDT_dmxu_poll_wait_for_event (../../../../mpich-4.0.1/src/pm/hydra/tools/demu[proxy:0:[email protected]] HYD_pmcd_pmip_control_cmd_cb (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmip_cb.c:899): assert (!closed) failed [proxy:0:[email protected]] HYDT_dmxu_poll_wait_for_event (../../../../mpich-4.0.1/src/pm/hydra/tools/demudemux_poll.c:76): callback returned error status [proxy:0:[email protected]] main (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmip.c:169): demux engine error waiting for event demux_poll.c:76): callback returned error status [proxy:0:[email protected]] main (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmip.c:169): demux engine error waiting for event [proxy:0:[email protected]] HYD_pmcd_pmip_control_cmd_cb (../../../../mpich-4.0.1/src/pm/hydra/pm/pmiserv/pmip_cb.c:899): assert (!closed) failed

1 0

Re: [mpich-discuss] mpiexec : multi nodes and multi-cores questions
by Zhou, Hui 06 May '22

06 May '22

Hi Nicholas, Assuming ParaView is using the same behavior as upstream hydra * -np 8 should launch 8 processes, 4 on each node * -np 4 should launch 4 processes, 2 on each node * To launch 4 processes on one node, try -hosts compute0:4,compute1:4 -np 4 * The number 4 behind each host instructs hydra to assign the first 4 ranks to the host before moving on to another assignment, the default is 1. Hydra uses round-robin assignment policy Hope it helps, -- Hui ________________________________ From: Nicholas Yue via discuss <discuss(a)mpich.org> Sent: Friday, May 6, 2022 11:11 AM To: discuss(a)mpich.org <discuss(a)mpich.org> Cc: Nicholas Yue <yue.nicholas(a)gmail.com> Subject: [mpich-discuss] mpiexec : multi nodes and multi-cores questions Hi, I am using mpiexec from Paraview which from the `help` print out, indicates that it is derived from MPICH ``` Please see the intructions provided at http://wiki.mpich.org/mpich/index.php/Using_the_Hydra_Process_Manager for further details ``` so I thought I might ask some questions on this mailing list. I have set up a two node cluster, each compute node has 4 cores To fully utilise all the cores in both nodes, is this the correct way to launch pvserver ? ``` /shared/ParaView-5.10.1-osmesa-MPI-Linux-Python3.9-x86_64/bin/mpiexec -hosts compute0,compute1 -np 8 /shared/ParaView-5.10.1-osmesa-MPI-Linux-Python3.9-x86_64/bin/pvserver ``` If I change to `-np 4` would mpiexec use only compute0 or would it still run on both compute0 and compute1 but use only 2 cores of each node ? Cheers -- Nicholas Yue https://www.linkedin.com/in/nicholasyue/

1 0

mpiexec : multi nodes and multi-cores questions
by Nicholas Yue 06 May '22

06 May '22

Hi, I am using mpiexec from Paraview which from the `help` print out, indicates that it is derived from MPICH ``` Please see the intructions provided at http://wiki.mpich.org/mpich/index.php/Using_the_Hydra_Process_Manager for further details ``` so I thought I might ask some questions on this mailing list. I have set up a two node cluster, each compute node has 4 cores To fully utilise all the cores in both nodes, is this the correct way to launch pvserver ? ``` /shared/ParaView-5.10.1-osmesa-MPI-Linux-Python3.9-x86_64/bin/mpiexec -hosts compute0,compute1 -np 8 /shared/ParaView-5.10.1-osmesa-MPI-Linux-Python3.9-x86_64/bin/pvserver ``` If I change to `-np 4` would mpiexec use only compute0 or would it still run on both compute0 and compute1 but use only 2 cores of each node ? Cheers -- Nicholas Yue https://www.linkedin.com/in/nicholasyue/

1 0

Re: [mpich-discuss] libfabric failure during mpich install
by Zhou, Hui 06 May '22

06 May '22

Try configure libfabric with --enable-direct=sockets. You can pass the option directly to MPICH's configure and it should pass it down to libfabric -- Hui ________________________________ From: Marshall Tabetah via discuss <discuss(a)mpich.org> Sent: Friday, May 6, 2022 10:08 AM To: discuss(a)mpich.org <discuss(a)mpich.org> Cc: Marshall Tabetah <met4t(a)virginia.edu> Subject: [mpich-discuss] libfabric failure during mpich install Hello, Team As I attempted to configure mpich-4.0.2 in my cygwin terminal, everything went on well until it failed to configure libfabric. The following error message was thus released upon termination. error: libfabric only builds on Linux, OS X, and FreeBSD. When I find out more information about libfabric, it seems it has support for Windows, so I do not surely know where the error comes from. Anyway, I hereby attach the files that communicate the status of the attempted configuration. Files that are not attached are those that were not produced. I appreciate further discussion/orientation. Cheers, Marshall

1 0

libfabric failure during mpich install
by Marshall Tabetah 06 May '22

06 May '22

Hello, Team As I attempted to configure mpich-4.0.2 in my cygwin terminal, everything went on well until it failed to configure libfabric. The following error message was thus released upon termination. error: libfabric only builds on Linux, OS X, and FreeBSD. When I find out more information about libfabric, it seems it has support for Windows, so I do not surely know where the error comes from. Anyway, I hereby attach the files that communicate the status of the attempted configuration. Files that are not attached are those that were not produced. I appreciate further discussion/orientation. Cheers, Marshall

1 0

Re: [mpich-discuss] [EXTERNAL] Re: error building cuda from yaksa
by Allen McIntosh 02 May '22

02 May '22

Installing the libtool-bin package also made the problem go away. (This was an Ubuntu system. The package name may be different on another distribution.) On 5/2/22 2:02 PM, Allen McIntosh wrote: > That was what I thought also. Unfortunately this doesn't work. The > purpose of setting $LIBTOOL_VERSION is to embed the version in the .lo > file $LO_FILEPATH that is created in the next statement. Although the > version is placed in something that appears to be a comment, it is > required later by something else called 'libtool', and it is > considered to be an error if the version is missing: > > libtool: error: 'src/backend/cuda/pup/yaksuri_cudai_pup__Bool.lo' is > not a valid libtool object > > The file contains the line > # Generated by > > This is a rather cryptic error message, but it goes away if the > libtool invocation on line 44 is changed to './libtool'. That is > marginally OK if cudalt.sh is only invoked in that directory (which > seems to be true just now) but it's not a permanent solution IMHO. > > I have attached the build log for whatever that's worth. Let me know > if you want any config logs. > > On 5/2/22 11:01 AM, Zhou, Hui wrote: >> Hi Allen, >> >> The line was just getting a libtool version to be included in a >> comment. I suspect simply deleting the line would work fine. Could >> you try that? >> >> Posting yaksa related questions here is fine. Don't worry about >> reposting to yaksa-users. >> >> -- >> Hui >> ------------------------------------------------------------------------ >> *From:* Allen McIntosh via discuss <discuss(a)mpich.org> >> *Sent:* Monday, May 2, 2022 9:22 AM >> *To:* discuss(a)mpich.org <discuss(a)mpich.org> >> *Cc:* Allen McIntosh <aamcintosh(a)peratonlabs.com> >> *Subject:* [mpich-discuss] error building cuda from yaksa >> >> Mpich version: 4.0.2 >> OS: Ubuntu 20.04 (but likely irrelevant) >> >> Line 45 (approximately) of >> mpich-4.0.2/modules/yaksa/src/backend/cuda/cudalt.sh invokes libtool >> without providing its own version. This results in an error if there is >> no system version of libtool. I got around this by changing the >> invocation to "./libtool", but that is pretty ugly. I have asked to >> have libtool-bin installed on the build system. I can post with any >> results. >> >> [I see that I really should have posted this to yaksa-users. I will >> subscribe and post there.] >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >

1 0

Re: [mpich-discuss] [EXTERNAL] Re: error building cuda from yaksa
by Allen McIntosh 02 May '22

02 May '22

That was what I thought also. Unfortunately this doesn't work. The purpose of setting $LIBTOOL_VERSION is to embed the version in the .lo file $LO_FILEPATH that is created in the next statement. Although the version is placed in something that appears to be a comment, it is required later by something else called 'libtool', and it is considered to be an error if the version is missing: libtool: error: 'src/backend/cuda/pup/yaksuri_cudai_pup__Bool.lo' is not a valid libtool object The file contains the line # Generated by This is a rather cryptic error message, but it goes away if the libtool invocation on line 44 is changed to './libtool'. That is marginally OK if cudalt.sh is only invoked in that directory (which seems to be true just now) but it's not a permanent solution IMHO. I have attached the build log for whatever that's worth. Let me know if you want any config logs. On 5/2/22 11:01 AM, Zhou, Hui wrote: > Hi Allen, > > The line was just getting a libtool version to be included in a > comment. I suspect simply deleting the line would work fine. Could you > try that? > > Posting yaksa related questions here is fine. Don't worry about > reposting to yaksa-users. > > -- > Hui > ------------------------------------------------------------------------ > *From:* Allen McIntosh via discuss <discuss(a)mpich.org> > *Sent:* Monday, May 2, 2022 9:22 AM > *To:* discuss(a)mpich.org <discuss(a)mpich.org> > *Cc:* Allen McIntosh <aamcintosh(a)peratonlabs.com> > *Subject:* [mpich-discuss] error building cuda from yaksa > > Mpich version: 4.0.2 > OS: Ubuntu 20.04 (but likely irrelevant) > > Line 45 (approximately) of > mpich-4.0.2/modules/yaksa/src/backend/cuda/cudalt.sh invokes libtool > without providing its own version. This results in an error if there is > no system version of libtool. I got around this by changing the > invocation to "./libtool", but that is pretty ugly. I have asked to > have libtool-bin installed on the build system. I can post with any > results. > > [I see that I really should have posted this to yaksa-users. I will > subscribe and post there.] > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] error building cuda from yaksa
by Zhou, Hui 02 May '22

02 May '22

Hi Allen, The line was just getting a libtool version to be included in a comment. I suspect simply deleting the line would work fine. Could you try that? Posting yaksa related questions here is fine. Don't worry about reposting to yaksa-users. -- Hui ________________________________ From: Allen McIntosh via discuss <discuss(a)mpich.org> Sent: Monday, May 2, 2022 9:22 AM To: discuss(a)mpich.org <discuss(a)mpich.org> Cc: Allen McIntosh <aamcintosh(a)peratonlabs.com> Subject: [mpich-discuss] error building cuda from yaksa Mpich version: 4.0.2 OS: Ubuntu 20.04 (but likely irrelevant) Line 45 (approximately) of mpich-4.0.2/modules/yaksa/src/backend/cuda/cudalt.sh invokes libtool without providing its own version. This results in an error if there is no system version of libtool. I got around this by changing the invocation to "./libtool", but that is pretty ugly. I have asked to have libtool-bin installed on the build system. I can post with any results. [I see that I really should have posted this to yaksa-users. I will subscribe and post there.] _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0