Re: [OMPI devel] Annual OMPI membership review: SVN accounts
You can remove Wesley. george. On Jul 9, 2013, at 0:32, "Jeff Squyres (jsquyres)" wrote: > Tennessee > > bosilca: George Bosilca > bouteill: Aurelien Bouteiller > wbland: Wesley Bland **NO COMMITS IN LAST YEAR**
Re: [OMPI devel] Annual OMPI membership review: SVN accounts
Le 09/07/2013 00:32, Jeff Squyres (jsquyres) a écrit : > INRIA > > bgoglin: Brice Goglin > arougier: Antoine Rougier > sthibaul: Samuel Thibault > mercier: Guillaume Mercier **NO COMMITS IN LAST YEAR** > nfurmento:Nathalie Furmento **NO COMMITS IN LAST > YEAR** > herault: Thomas Herault **NO COMMITS IN LAST YEAR** > You can remove arougier. herault isn't Inria anymore, he's UTK now, not sure what to do with him. Brice
Re: [OMPI devel] Annual OMPI membership review: SVN accounts
Please keep all three accounts from Dresden. > Dresden > = > knuepfer: Andreas Knuepfer **NO COMMITS IN > LAST YEAR** > bwesarg: Bert Wesarg **NO COMMITS IN LAST YEAR** > jurenz: Matthias Jurenz > -- Dr. rer. nat. Andreas Knüpfer Senior Scientist Technische Universität Dresden Center for Information Services and HPC (ZIH) Willersbau A114, Zellescher Weg 12, 01062 Dresden Tel. +49 351 463 38323 Fax. +49 351 463 37773 Email: andreas.knuep...@tu-dresden.de smime.p7s Description: S/MIME Cryptographic Signature
Re: [OMPI devel] No such file(s) or directory
(giggling) No, it's unsafe. I've disabled 'trace' for now. On a more serious note, why not adding those, if they should be here? Making check in mca/sensor/resusage make[2]: Entering directory '/usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/build/orte/mca/sensor/resusage' CC sensor_resusage.lo /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/orte/mca/sensor/resusage/sensor_resusage.c:35:28: fatal error: orte/mca/db/db.h: No such file or directory #include "orte/mca/db/db.h" ^ compilation terminated. Makefile:1594: recipe for target 'sensor_resusage.lo' failed On Tue, Jul 9, 2013 at 1:28 AM, Ralph Castain wrote: > Is it safe to say that you are going thru an exercise testing every option > that exists? Just want to know so I can set expectations > > > On Jul 8, 2013, at 11:47 AM, Vasiliy wrote: > >> there're more to come: >> >> Making all in mca/sensor/resusage >> make[2]: Entering directory >> '/usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/build/orte/mca/sensor/resusage' >> CC sensor_resusage.lo >> /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/orte/mca/sensor/resusage/sensor_resusage.c:35:28: >> fatal error: orte/mca/db/db.h: No such file or directory >> #include "orte/mca/db/db.h" >>^ >> compilation terminated. >> Makefile:1594: recipe for target 'sensor_resusage.lo' failed >> >> >> On Mon, Jul 8, 2013 at 8:38 PM, Vasiliy wrote: >>> Oh, well, it does not: >>> >>> Making all in mca/db/sqlite >>> make[2]: Entering directory >>> '/usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/build/opal/mca/db/sqlite' >>> CC libmca_db_sqlite_la-db_sqlite_component.lo >>> /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/opal/mca/db/sqlite/db_sqlite_component.c: >>> In function ‘sqlite_component_query’: >>> /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/opal/mca/db/sqlite/db_sqlite_component.c:93:17: >>> warning: assignment from incompatible pointer type [enabled by >>> default] >>> *module = (mca_base_module_t*)&opal_db_sqlite_module; >>> ^ >>> /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/opal/mca/db/sqlite/db_sqlite_component.c: >>> In function ‘sqlite_component_close’: >>> /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/opal/mca/db/sqlite/db_sqlite_component.c:104:12: >>> error: ‘ORTE_SUCCESS’ undeclared (first use in this function) >>> return ORTE_SUCCESS; >>>^ >>> /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/opal/mca/db/sqlite/db_sqlite_component.c:104:12: >>> note: each undeclared identifier is reported only once for each >>> function it appears in >>> /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/opal/mca/db/sqlite/db_sqlite_component.c: >>> In function ‘sqlite_component_register’: >>> /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/opal/mca/db/sqlite/db_sqlite_component.c:127:12: >>> error: ‘ORTE_SUCCESS’ undeclared (first use in this function) >>> return ORTE_SUCCESS; >>>^ >>> Makefile:1608: recipe for target >>> 'libmca_db_sqlite_la-db_sqlite_component.lo' failed >>> make[2]: *** [libmca_db_sqlite_la-db_sqlite_component.lo] Error 1 >>> CC libmca_db_sqlite_la-db_sqlite.lo >>> /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/opal/mca/db/sqlite/db_sqlite.c:39:39: >>> fatal error: opal/runtime/opal_globals.h: No such file or directory >>> #include "opal/runtime/opal_globals.h" >>> ^ >>> compilation terminated. >>> >>> On Mon, Jul 8, 2013 at 8:28 PM, Ralph Castain wrote: Actually, those headers needed to be deleted - done. I take it you were deliberately trying to build that support? Otherwise, it shouldn't have built. On Jul 8, 2013, at 11:11 AM, Vasiliy wrote: > Could somebody add these required headers to the repository? Thank you > in advance: > > Making all in mca/db/sqlite > make[2]: Entering directory > '/usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/build/opal/mca/db/sqlite' > CC libmca_db_sqlite_la-db_sqlite_component.lo > CC libmca_db_sqlite_la-db_sqlite.lo > /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/opal/mca/db/sqlite/db_sqlite_component.c:23:33: > fatal error: opal/util/proc_info.h: No such file or directory > #include "opal/util/proc_info.h" >^ > compilation terminated. > Makefile:1608: recipe for target > 'libmca_db_sqlite_la-db_sqlite_component.lo' failed > make[2]: *** [libmca_db_sqlite_la-db_sqlite_component.lo] Error 1 > make[2]: *** Waiting for unfinished jobs > /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/opal/mca/db/sqlite/db_sqlite.c:39:39: > fatal error: opal/mca/errmgr/base/base.h: No such file or directory > #include
Re: [OMPI devel] Annual OMPI membership review: SVN accounts
Mellanox accounts - you may delete Lenny's account. Alina would like to start contributing, however, when I go into Trac to assign her a ticket, her username,"alinas", isn't available in the list of possible owners. Please advise. Josh -Original Message- From: devel-boun...@open-mpi.org [mailto:devel-boun...@open-mpi.org] On Behalf Of Jeff Squyres (jsquyres) Sent: Monday, July 08, 2013 6:33 PM To: Open MPI Developers List Subject: [OMPI devel] Annual OMPI membership review: SVN accounts According to https://svn.open-mpi.org/trac/ompi/wiki/Admistrative%20rules, it is time for our annual review of Open MPI SVN accounts of these SVN repos: hwloc, mtt, ompi-docs, ompi-tests, ompi-www, ompi. *** Organizations must reply by COB Friday, 12 July, 2013 *** *** No reply means: delete all of my organization's SVN accounts Each organization must reply and specify which of their accounts can stay and which should go. I cross-referenced the SVN logs from all of our SVN repositories to see who has not committed anything in the past year. *** I strongly recommend deleting accounts who have not committed in the last year. *** Other accounts can be deleted, too (e.g., those who have left a given organization). bakeyournoodle.com (???) == tonyb:Tony Breeds **NO COMMITS IN LAST YEAR** Cisco = dgoodell: Dave Goodell jsquyres: Jeff Squyres Indiana == lums: Andrew Lumsdaine **NO COMMITS IN LAST YEAR** adkulkar: Abhishek Kulkarni afriedle: Andrew Friedley **NO COMMITS IN LAST YEAR** timattox: Tim Mattox **NO COMMITS IN LAST YEAR** U. Houston = edgar:Edgar Gabriel vvenkatesan:Vishwanath Venkatesan Mellanox == alekseys: Aleksey Senin kliteyn: Yevgeny Kliteynik miked:Mike Dubman lennyve: Lenny Verkhovsky **NO COMMITS IN LAST YEAR** yaeld:Yael Dayan vasily: Vasily Philipov amikheev: Alex Mikheev alex: Alexander Margolin alinas: Alina Sklarevich **NO COMMITS IN LAST YEAR** igoru:Igor Usarov jladd:Joshua Ladd yosefe: Yossi rlgraham: Rich Graham **NO COMMITS IN LAST YEAR** Tennessee bosilca: George Bosilca bouteill: Aurelien Bouteiller wbland: Wesley Bland **NO COMMITS IN LAST YEAR** hlrs.de === shiqing: Shiqing Fan hpcchris: Christoph Niethammer rusraink: Rainer Keller **NO COMMITS IN LAST YEAR** IBM == jnysal: Nysal Jan K A **NO COMMITS IN LAST YEAR** cyeoh:Chris Yeoh bbenton: Brad Benton INRIA bgoglin: Brice Goglin arougier: Antoine Rougier sthibaul: Samuel Thibault mercier: Guillaume Mercier **NO COMMITS IN LAST YEAR** nfurmento:Nathalie Furmento **NO COMMITS IN LAST YEAR** herault: Thomas Herault **NO COMMITS IN LAST YEAR** LANL hjelmn: Nathan Hjelm samuel: Samuel K. Gutierrez NVIDIA == rolfv:Rolf Vandevaart U. Wisconsin La Crosse jjhursey: Joshua Hursey Intel rhc: Ralph Castain Chelsio / OGC = swise:Steve Wise Oracle == emallove: Ethan Mallove **NO COMMITS IN LAST YEAR** eugene: Eugene Loh tdd: Terry Dontje ORNL manjugv: Manjunath, Gorentla Venkata naughtont:Thomas Naughton pasha:Pavel Shamis Sandia == brbarret: Brian Barrett memoryhole:Kyle Wheeler **NO COMMITS IN LAST YEAR** ktpedre: Kevin Pedretti **NO COMMITS IN LAST YEAR** mjleven: Michael Levenhagen **NO COMMITS IN LAST YEAR** rbbrigh: Ron Brightwell **NO COMMITS IN LAST YEAR** Dresden = knuepfer: Andreas Knuepfer **NO COMMITS IN LAST YEAR** bwesarg: Bert Wesarg **NO COMMITS IN LAST YEAR** jurenz: Matthias Jurenz -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] Annual OMPI membership review: SVN accounts
Indeed Thomas is now part of UTK. George. On Jul 9, 2013, at 7:47, Brice Goglin wrote: > Le 09/07/2013 00:32, Jeff Squyres (jsquyres) a écrit : >> INRIA >> >> bgoglin: Brice Goglin >> arougier: Antoine Rougier >> sthibaul: Samuel Thibault >> mercier: Guillaume Mercier **NO COMMITS IN LAST YEAR** >> nfurmento:Nathalie Furmento **NO COMMITS IN >> LAST YEAR** >> herault: Thomas Herault **NO COMMITS IN LAST YEAR** > > You can remove arougier. > herault isn't Inria anymore, he's UTK now, not sure what to do with him. > > Brice > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] Annual OMPI membership review: SVN accounts
You can remove Shiqing. Rainer should be listed in future under hft-stuttgart.de. ;) Regards Christoph > hlrs.de > === > shiqing: Shiqing Fan > hpcchris: Christoph Niethammer > rusraink: Rainer Keller **NO COMMITS IN LAST > YEAR**
[OMPI devel] Alina's SVN account (was: Annual OMPI membership review: SVN accounts)
On Jul 9, 2013, at 3:50 AM, Joshua Ladd wrote: > Alina would like to start contributing, however, when I go into Trac to > assign her a ticket, her username,"alinas", isn't available in the list of > possible owners. She needs to sign up for a Trac account. If she uses the same email address + username, it should automatically associate with her SVN account. -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI devel] a bogus warning: undefined symbols not allowed in x86_64-pc-cygwin shared libraries
I'll have to look into that. It looks like with all my humble patches it should compile and pass the tests successfully even if compiled with -march=native -mtune=native -Ofast+ optimization, and all the perks enabled. That is, if the missing headers will be made available. No, I haven't been contacted by Mellanox nor by any respectful organization mentioned on the OMPI membership list to support Open MPI under Cygwin 32/64-bit. Even if I have a degree in Physics, invested a personal fortune in my Quantitative..., in my second-third degree studies in Switzerland, and have 20+ years of work experience in the IT field, quite recently with the Brutus cluster, who would be willing to look for a new hire nowadays? On Mon, Jul 8, 2013 at 9:09 PM, Jeff Squyres (jsquyres) wrote: > This is not enough information to know what is going wrong with the debugger > library -- all you pasted was a link failure with no surrounding context... > > Don't forget that we officially dropped Windows support in v1.7. Cygwin > supposedly works, but we're not testing it, so I wouldn't be surprised if > there's bit rot in there. > > Are you the same Vasily from Mellanox? If so, are you saying that Mellanox > is working to support Open MPI under Cygwin? > > > > On Jul 8, 2013, at 3:00 PM, Vasiliy wrote: > >> I haven't checked that yet, however, from my experience, creating a >> shared library manually from the same compiled objects never was a >> problem at a later stage, it's usually because of Makefile's >> inconsistent dependencies ordering: >> >> $ uname -srvmo >> CYGWIN_NT-6.1 1.7.21(0.267/5/3) 2013-06-28 10:03 x86_64 Cygwin >> >> >> Making all in debuggers >> make[2]: Entering directory >> '/usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/build/ompi/debuggers' >> CC libdebuggers_la-ompi_debuggers.lo >> CCLD libdebuggers.la >> CC ompi_debugger_canary.lo >> CCLD libompi_debugger_canary.la >> CC libompi_dbg_msgq_la-ompi_msgq_dll.lo >> CC libompi_dbg_msgq_la-ompi_common_dll.lo >> CCLD libompi_dbg_msgq.la >> libtool: warning: undefined symbols not allowed in >> x86_64-unknown-cygwin shared libraries >> make[2]: Leaving directory >> '/usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/build/ompi/debuggers' >> >> ___ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] a bogus warning: undefined symbols not allowed in x86_64-pc-cygwin shared libraries
On Jul 9, 2013, at 7:01 AM, Vasiliy wrote: > I'll have to look into that. It looks like with all my humble patches > it should compile and pass the tests successfully even if compiled > with -march=native -mtune=native -Ofast+ optimization, and all the > perks enabled. That is, if the missing headers will be made available. Ok. What was the error in the debugger library? > No, I haven't been contacted by Mellanox nor by any respectful Ok, I just couldn't tell -- Mellanox has a "Vasily", too, and they sometimes use alternate email addresses (and your last name is not listed in your email address :-) ). -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI devel] a bogus warning: undefined symbols not allowed in x86_64-pc-cygwin shared libraries
Hi, Marco, It is a looong string of characters, times as yours, and I'm actually making a DSO build with everything included. Yes, it is the bleeding-edge, however, patched Open MPI version 1.9a1 sources, on Cygwin 64-bit version 1.7.21-6. I have updated dozens of Cygwin packages to their 'bleeding-edge' revisions, and successfully tested and compiled many of those, flexible enough, further with -Ofast and "plus" optimization for my projects. This has resulted in a tremendous speed increase, full multithreading, and hot deliverables due to faster execution time. While I don't represent any organization view it's still an amateur work done to the detriment of time for job hunting. I probably need to pay more attention to the latter, so, to find out if I could complete a DSO build before the hunting season starts. There is a well-funded hope, though. Regards, Vasiliy On Mon, Jul 8, 2013 at 9:13 PM, marco atzeri wrote: > Hi Vasiliy > how do you called configure ? > > I have not tested 1.9 on cygwin 64, but > 1.7.1 cygwin64 package was built with > > configure \ > LDFLAGS="-Wl,--export-all-symbols -Wl,-no-undefined" \ > --disable-mca-dso \ > --disable-sysv-shmem \ > --without-udapl \ > --enable-cxx-exceptions \ > --with-threads=posix \ > --without-cs-fs \ > --enable-heterogeneous \ > --with-mpi-param_check=always \ > --enable-contrib-no-build=vt,libompitrace \ > > --enable-mca-no-build=paffinity,installdirs-windows,timer-windows,shmem-sysv > > > Regards > Marco > > > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] a bogus warning: undefined symbols not allowed in x86_64-pc-cygwin shared libraries
No, he's not "our" Vasily :). I thought it was also until today. He had the build issues last week - I thought this was "our" Vasily also, that's why I responded! I'm in Israel now and just spoke with Vasily; he was confused as to why I was emailing him about SVN problems. Josh -Original Message- From: devel-boun...@open-mpi.org [mailto:devel-boun...@open-mpi.org] On Behalf Of Vasiliy Sent: Tuesday, July 09, 2013 7:02 AM To: Open MPI Developers Subject: Re: [OMPI devel] a bogus warning: undefined symbols not allowed in x86_64-pc-cygwin shared libraries I'll have to look into that. It looks like with all my humble patches it should compile and pass the tests successfully even if compiled with -march=native -mtune=native -Ofast+ optimization, and all the perks enabled. That is, if the missing headers will be made available. No, I haven't been contacted by Mellanox nor by any respectful organization mentioned on the OMPI membership list to support Open MPI under Cygwin 32/64-bit. Even if I have a degree in Physics, invested a personal fortune in my Quantitative..., in my second-third degree studies in Switzerland, and have 20+ years of work experience in the IT field, quite recently with the Brutus cluster, who would be willing to look for a new hire nowadays? On Mon, Jul 8, 2013 at 9:09 PM, Jeff Squyres (jsquyres) wrote: > This is not enough information to know what is going wrong with the debugger > library -- all you pasted was a link failure with no surrounding context... > > Don't forget that we officially dropped Windows support in v1.7. Cygwin > supposedly works, but we're not testing it, so I wouldn't be surprised if > there's bit rot in there. > > Are you the same Vasily from Mellanox? If so, are you saying that Mellanox > is working to support Open MPI under Cygwin? > > > > On Jul 8, 2013, at 3:00 PM, Vasiliy wrote: > >> I haven't checked that yet, however, from my experience, creating a >> shared library manually from the same compiled objects never was a >> problem at a later stage, it's usually because of Makefile's >> inconsistent dependencies ordering: >> >> $ uname -srvmo >> CYGWIN_NT-6.1 1.7.21(0.267/5/3) 2013-06-28 10:03 x86_64 Cygwin >> >> >> Making all in debuggers >> make[2]: Entering directory >> '/usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/build/ompi/debuggers' >> CC libdebuggers_la-ompi_debuggers.lo >> CCLD libdebuggers.la >> CC ompi_debugger_canary.lo >> CCLD libompi_debugger_canary.la >> CC libompi_dbg_msgq_la-ompi_msgq_dll.lo >> CC libompi_dbg_msgq_la-ompi_common_dll.lo >> CCLD libompi_dbg_msgq.la >> libtool: warning: undefined symbols not allowed in >> x86_64-unknown-cygwin shared libraries >> make[2]: Leaving directory >> '/usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/build/ompi/debuggers' >> >> ___ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] a bogus warning: undefined symbols not allowed in x86_64-pc-cygwin shared libraries
I do also! It does not take long to figure our my last name, if the headers of my emails will get scrutinized, though ;-) ) No doubts, I'll assemble the shared debugger library, it doesn't need to be patched; what I was talking about it's the SVN sources as a whole do need that. On Tue, Jul 9, 2013 at 1:21 PM, Jeff Squyres (jsquyres) wrote: > On Jul 9, 2013, at 7:01 AM, Vasiliy wrote: > >> I'll have to look into that. It looks like with all my humble patches >> it should compile and pass the tests successfully even if compiled >> with -march=native -mtune=native -Ofast+ optimization, and all the >> perks enabled. That is, if the missing headers will be made available. > > Ok. What was the error in the debugger library? > >> No, I haven't been contacted by Mellanox nor by any respectful > > Ok, I just couldn't tell -- Mellanox has a "Vasily", too, and they sometimes > use alternate email addresses (and your last name is not listed in your email > address :-) ). > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] a bogus warning: undefined symbols not allowed in x86_64-pc-cygwin shared libraries
Il 7/9/2013 2:01 PM, Vasiliy ha scritto: Hi, Marco, It is a looong string of characters, times as yours, and I'm actually making a DSO build with everything included. Yes, it is the bleeding-edge, however, patched Open MPI version 1.9a1 sources, on Cygwin 64-bit version 1.7.21-6. I have updated dozens of Cygwin packages to their 'bleeding-edge' revisions, and successfully tested and compiled many of those, flexible enough, further with -Ofast and "plus" optimization for my projects. This has resulted in a tremendous speed increase, full multithreading, and hot deliverables due to faster execution time. already building first openmpi package some months ago was bleeding edge ;-) You are welcome to the party and let me know how proceed with dso; on my build it is disabled on purpose as I was not able to build it also on 32bit due to the unclear dependency tree. the undefined warning is usually releated to some type of LDFLAGS="-Wl,-no-undefined" variants needed. Unfortunately latest gcc does not ignore any more the "-no-undefined" as unknown word and passing it to libtool is becoming a bit harder that was in the past. Please remind that Cygwin 64 is also bleeding-edge; it is a good beta but still a beta. While I don't represent any organization view it's still an amateur work done to the detriment of time for job hunting. I probably need to pay more attention to the latter, so, to find out if I could complete a DSO build before the hunting season starts. There is a well-funded hope, though. I can not help here. Writing software is not my main activity, just a side hobby. Regards, Vasiliy Regards Marco
Re: [OMPI devel] a bogus warning: undefined symbols not allowed in x86_64-pc-cygwin shared libraries
Hi there, and hey, with my last name I almost could claim an ownership of one of the Israeli sights which was named after me ;) or either it was my last name named after, likely both lost in translation :) ) On Tue, Jul 9, 2013 at 2:14 PM, Joshua Ladd wrote: > No, he's not "our" Vasily :). I thought it was also until today. He had the > build issues last week - I thought this was "our" Vasily also, that's why I > responded! I'm in Israel now and just spoke with Vasily; he was confused as > to why I was emailing him about SVN problems. > > > > Josh > > -Original Message- > From: devel-boun...@open-mpi.org [mailto:devel-boun...@open-mpi.org] On > Behalf Of Vasiliy > Sent: Tuesday, July 09, 2013 7:02 AM > To: Open MPI Developers > Subject: Re: [OMPI devel] a bogus warning: undefined symbols not allowed in > x86_64-pc-cygwin shared libraries > > I'll have to look into that. It looks like with all my humble patches it > should compile and pass the tests successfully even if compiled with > -march=native -mtune=native -Ofast+ optimization, and all the perks enabled. > That is, if the missing headers will be made available. > > No, I haven't been contacted by Mellanox nor by any respectful organization > mentioned on the OMPI membership list to support Open MPI under Cygwin > 32/64-bit. Even if I have a degree in Physics, invested a personal fortune in > my Quantitative..., in my second-third degree studies in Switzerland, and > have 20+ years of work experience in the IT field, quite recently with the > Brutus cluster, who would be willing to look for a new hire nowadays? > > On Mon, Jul 8, 2013 at 9:09 PM, Jeff Squyres (jsquyres) > wrote: >> This is not enough information to know what is going wrong with the debugger >> library -- all you pasted was a link failure with no surrounding context... >> >> Don't forget that we officially dropped Windows support in v1.7. Cygwin >> supposedly works, but we're not testing it, so I wouldn't be surprised if >> there's bit rot in there. >> >> Are you the same Vasily from Mellanox? If so, are you saying that Mellanox >> is working to support Open MPI under Cygwin? >> >> >> >> On Jul 8, 2013, at 3:00 PM, Vasiliy wrote: >> >>> I haven't checked that yet, however, from my experience, creating a >>> shared library manually from the same compiled objects never was a >>> problem at a later stage, it's usually because of Makefile's >>> inconsistent dependencies ordering: >>> >>> $ uname -srvmo >>> CYGWIN_NT-6.1 1.7.21(0.267/5/3) 2013-06-28 10:03 x86_64 Cygwin >>> >>> >>> Making all in debuggers >>> make[2]: Entering directory >>> '/usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/build/ompi/debuggers' >>> CC libdebuggers_la-ompi_debuggers.lo >>> CCLD libdebuggers.la >>> CC ompi_debugger_canary.lo >>> CCLD libompi_debugger_canary.la >>> CC libompi_dbg_msgq_la-ompi_msgq_dll.lo >>> CC libompi_dbg_msgq_la-ompi_common_dll.lo >>> CCLD libompi_dbg_msgq.la >>> libtool: warning: undefined symbols not allowed in >>> x86_64-unknown-cygwin shared libraries >>> make[2]: Leaving directory >>> '/usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/build/ompi/debuggers' >>> >>> ___ >>> devel mailing list >>> de...@open-mpi.org >>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >> >> >> -- >> Jeff Squyres >> jsquy...@cisco.com >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> >> ___ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] No such file(s) or directory
No issue with doing so. If this was someone trying to use it, I'd put it at a high priority. If just someone trying all the configure options, then a lower priority. The problem stems from a little bit-rot. Those components are updated and working on a side branch being used by my old company, but I didn't make it a priority to bring them across as nobody else was using them. On Jul 8, 2013, at 11:44 PM, Vasiliy wrote: > (giggling) No, it's unsafe. I've disabled 'trace' for now. On a more > serious note, why not adding those, if they should be here? > > Making check in mca/sensor/resusage > make[2]: Entering directory > '/usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/build/orte/mca/sensor/resusage' > CC sensor_resusage.lo > /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/orte/mca/sensor/resusage/sensor_resusage.c:35:28: > fatal error: orte/mca/db/db.h: No such file or directory > #include "orte/mca/db/db.h" >^ > compilation terminated. > Makefile:1594: recipe for target 'sensor_resusage.lo' failed > > > On Tue, Jul 9, 2013 at 1:28 AM, Ralph Castain wrote: >> Is it safe to say that you are going thru an exercise testing every option >> that exists? Just want to know so I can set expectations >> >> >> On Jul 8, 2013, at 11:47 AM, Vasiliy wrote: >> >>> there're more to come: >>> >>> Making all in mca/sensor/resusage >>> make[2]: Entering directory >>> '/usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/build/orte/mca/sensor/resusage' >>> CC sensor_resusage.lo >>> /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/orte/mca/sensor/resusage/sensor_resusage.c:35:28: >>> fatal error: orte/mca/db/db.h: No such file or directory >>> #include "orte/mca/db/db.h" >>> ^ >>> compilation terminated. >>> Makefile:1594: recipe for target 'sensor_resusage.lo' failed >>> >>> >>> On Mon, Jul 8, 2013 at 8:38 PM, Vasiliy wrote: Oh, well, it does not: Making all in mca/db/sqlite make[2]: Entering directory '/usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/build/opal/mca/db/sqlite' CC libmca_db_sqlite_la-db_sqlite_component.lo /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/opal/mca/db/sqlite/db_sqlite_component.c: In function ‘sqlite_component_query’: /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/opal/mca/db/sqlite/db_sqlite_component.c:93:17: warning: assignment from incompatible pointer type [enabled by default] *module = (mca_base_module_t*)&opal_db_sqlite_module; ^ /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/opal/mca/db/sqlite/db_sqlite_component.c: In function ‘sqlite_component_close’: /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/opal/mca/db/sqlite/db_sqlite_component.c:104:12: error: ‘ORTE_SUCCESS’ undeclared (first use in this function) return ORTE_SUCCESS; ^ /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/opal/mca/db/sqlite/db_sqlite_component.c:104:12: note: each undeclared identifier is reported only once for each function it appears in /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/opal/mca/db/sqlite/db_sqlite_component.c: In function ‘sqlite_component_register’: /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/opal/mca/db/sqlite/db_sqlite_component.c:127:12: error: ‘ORTE_SUCCESS’ undeclared (first use in this function) return ORTE_SUCCESS; ^ Makefile:1608: recipe for target 'libmca_db_sqlite_la-db_sqlite_component.lo' failed make[2]: *** [libmca_db_sqlite_la-db_sqlite_component.lo] Error 1 CC libmca_db_sqlite_la-db_sqlite.lo /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/opal/mca/db/sqlite/db_sqlite.c:39:39: fatal error: opal/runtime/opal_globals.h: No such file or directory #include "opal/runtime/opal_globals.h" ^ compilation terminated. On Mon, Jul 8, 2013 at 8:28 PM, Ralph Castain wrote: > Actually, those headers needed to be deleted - done. I take it you were > deliberately trying to build that support? Otherwise, it shouldn't have > built. > > On Jul 8, 2013, at 11:11 AM, Vasiliy wrote: > >> Could somebody add these required headers to the repository? Thank you >> in advance: >> >> Making all in mca/db/sqlite >> make[2]: Entering directory >> '/usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/build/opal/mca/db/sqlite' >> CC libmca_db_sqlite_la-db_sqlite_component.lo >> CC libmca_db_sqlite_la-db_sqlite.lo >> /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/opal/mca/db/sqlite/db_sqlite_component.c:23:33: >> fatal error: opal/util/proc_info.h: No such file or dire
Re: [OMPI devel] Annual OMPI membership review: SVN accounts
No changes here. >NVIDIA >== >rolfv:Rolf Vandevaart > --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ---
Re: [OMPI devel] the sensors do not compile
fixed now On Jul 8, 2013, at 11:43 AM, Vasiliy wrote: > It has been taken from the compilation log: > > Making all in mca/sensor/ft_tester > make[2]: Entering directory > '/usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/build/orte/mca/sensor/ft_tester' > CC sensor_ft_tester.lo > CC sensor_ft_tester_component.lo > /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/orte/mca/sensor/ft_tester/sensor_ft_tester_component.c: > In function ‘orte_sensor_ft_tester_register’: > /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/orte/mca/sensor/ft_tester/sensor_ft_tester_component.c:63:9: > error: expected identifier or ‘(’ before ‘)’ token > void) mca_base_var_register (c, "fail_prob", "Probability of > killing a single executable", > ^ > /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/orte/mca/sensor/ft_tester/sensor_ft_tester_component.c:74:35: > warning: passing argument 1 of ‘mca_base_var_register’ from > incompatible pointer type [enabled by default] > &mca_sensor_ft_tester_component.multi_fail); > ^ > In file included from > /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/opal/mca/base/base.h:35:0, > from > /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/orte/mca/sensor/ft_tester/sensor_ft_tester_component.c:14: > /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/opal/mca/base/mca_base_var.h:503:19: > note: expected ‘const char *’ but argument is of type ‘struct > mca_base_component_t *’ > OPAL_DECLSPEC int mca_base_var_register (const char *project_name, > const char *framework_name, > ^ > /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/orte/mca/sensor/ft_tester/sensor_ft_tester_component.c:74:35: > warning: passing argument 4 of ‘mca_base_var_register’ makes pointer > from integer without a cast [enabled by default] > &mca_sensor_ft_tester_component.multi_fail); > ^ > In file included from > /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/opal/mca/base/base.h:35:0, > from > /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/orte/mca/sensor/ft_tester/sensor_ft_tester_component.c:14: > /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/opal/mca/base/mca_base_var.h:503:19: > note: expected ‘const char *’ but argument is of type ‘int’ > OPAL_DECLSPEC int mca_base_var_register (const char *project_name, > const char *framework_name, > ^ > /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/orte/mca/sensor/ft_tester/sensor_ft_tester_component.c:74:35: > error: incompatible type for argument 10 of ‘mca_base_var_register’ > &mca_sensor_ft_tester_component.multi_fail); > ^ > In file included from > /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/opal/mca/base/base.h:35:0, > from > /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/orte/mca/sensor/ft_tester/sensor_ft_tester_component.c:14: > /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/opal/mca/base/mca_base_var.h:503:19: > note: expected ‘mca_base_var_info_lvl_t’ but argument is of type > ‘_Bool *’ > OPAL_DECLSPEC int mca_base_var_register (const char *project_name, > const char *framework_name, > ^ > /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/orte/mca/sensor/ft_tester/sensor_ft_tester_component.c:74:35: > error: too few arguments to function ‘mca_base_var_register’ > &mca_sensor_ft_tester_component.multi_fail); > ^ > In file included from > /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/opal/mca/base/base.h:35:0, > from > /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/orte/mca/sensor/ft_tester/sensor_ft_tester_component.c:14: > /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/opal/mca/base/mca_base_var.h:503:19: > note: declared here > OPAL_DECLSPEC int mca_base_var_register (const char *project_name, > const char *framework_name, > ^ > /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/orte/mca/sensor/ft_tester/sensor_ft_tester_component.c:81:35: > warning: passing argument 1 of ‘mca_base_var_register’ from > incompatible pointer type [enabled by default] > &daemon_fail_prob); > ^ > In file included from > /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/opal/mca/base/base.h:35:0, > from > /usr/src/64bit/release/openmpi/openmpi-1.9.0-a1/src/openmpi-1.9.0/orte/mca/sensor/ft_tester/sensor_ft_tester_component.c:14: > /u
Re: [OMPI devel] Annual OMPI membership review: SVN accounts
On 7/8/2013 3:32 PM, Jeff Squyres (jsquyres) wrote: According to https://svn.open-mpi.org/trac/ompi/wiki/Admistrative%20rules, it is time for our annual review of Open MPI SVN accounts of these SVN repos: hwloc, mtt, ompi-docs, ompi-tests, ompi-www, ompi. *** Organizations must reply by COB Friday, 12 July, 2013 *** *** No reply means: delete all of my organization's SVN accounts Each organization must reply and specify which of their accounts can stay and which should go. I cross-referenced the SVN logs from all of our SVN repositories to see who has not committed anything in the past year. Oracle == emallove: Ethan Mallove **NO COMMITS IN LAST YEAR** eugene: Eugene Loh tdd: Terry Dontje Please keep eugene, but close emallove and tdd.
Re: [OMPI devel] Annual OMPI membership review: SVN accounts
What, my SVN account is still there? I'm just a lurker now, so please remove timattox from SVN On Mon, Jul 8, 2013 at 6:32 PM, Jeff Squyres (jsquyres) wrote: > > Indiana > == > lums: Andrew Lumsdaine **NO COMMITS IN LAST > YEAR** > adkulkar: Abhishek Kulkarni > afriedle: Andrew Friedley **NO COMMITS IN LAST > YEAR** > timattox: Tim Mattox **NO COMMITS IN LAST YEAR** > > -- Tim Mattox, Ph.D. - I'm a bright... http://www.the-brights.net/ timat...@open-mpi.org || tmat...@gmail.com
[OMPI devel] MCA param levels
I just took a schwack at setting some MPI_T levels for the MCA parameters in the TCP and SM BTLs, and the mca_btl_base_param_register() function, which registers MCA params for all BTLs. https://svn.open-mpi.org/trac/ompi/changeset/28746 I make a wiki page to help developers choose MPI_T levels for their MCA params: https://svn.open-mpi.org/trac/ompi/wiki/MCAParamLevels Comments? -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI devel] MCA param levels
On Jul 9, 2013, at 5:49 PM, Jeff Squyres (jsquyres) wrote: > I just took a schwack at setting some MPI_T levels for the MCA parameters in > the TCP and SM BTLs, and the mca_btl_base_param_register() function, which > registers MCA params for all BTLs. > >https://svn.open-mpi.org/trac/ompi/changeset/28746 > > I make a wiki page to help developers choose MPI_T levels for their MCA > params: > >https://svn.open-mpi.org/trac/ompi/wiki/MCAParamLevels > you anticipated my very next question :-) > Comments? > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
