Hi
A short update of the upcoming release:
There are still outstanding issues that prevent going forward with the release (see https://docs.einsteintoolkit.org/et-docs/Release_coordination for current information).
The most important are:
- Some McLachlan testsuites are still failing. Peter wasn't able to find time to look at it, and won't have for the coming week. We need a volunteer to work on these. This is ticket 1995. - ExternalLibraries/MPI prevents Cactus from linking if built from the thorn-sources, on (at least some) Linux systems. The issue is described in ticket 2049. - Both SphericalHarmonicReconGen tests fail, for at least apparently different reasons (but since one is a segfault you never know)
Otherwise, the tests seem to run fine, on the few machines I've tested them on. We obviously need to test a lot more machines, which is also still out-standing.
Frank
On Sun, Jun 18, 2017 at 5:21 PM, Frank Loeffler knarf@cct.lsu.edu wrote:
Hi
A short update of the upcoming release:
There are still outstanding issues that prevent going forward with the release (see https://docs.einsteintoolkit.org/et-docs/Release_coordination for current information).
The most important are:
- Some McLachlan testsuites are still failing. Peter wasn't able to find
time to look at it, and won't have for the coming week. We need a volunteer to work on these. This is ticket 1995.
- ExternalLibraries/MPI prevents Cactus from linking if built from the
thorn-sources, on (at least some) Linux systems. The issue is described in ticket 2049.
Note that this has a straightforward work-around -- pass the respective options manually. This short before a release, I recommend going with a work-around instead of modifying Cactus's internal mechanism, which might break things.
-erik
- Both SphericalHarmonicReconGen tests fail, for at least apparently
different reasons (but since one is a segfault you never know)
Otherwise, the tests seem to run fine, on the few machines I've tested them on. We obviously need to test a lot more machines, which is also still out-standing.
Frank
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
On Mon, Jun 19, 2017 at 10:58:28AM -0400, Erik Schnetter wrote:
Note that this has a straightforward work-around -- pass the respective options manually. This short before a release, I recommend going with a work-around instead of modifying Cactus's internal mechanism, which might break things.
That's what the workaround would do: pass them manually in case the code finds itself on a Linux system. We cannot unconditionally add them in the thorn, because those Libraries might not exist on other systems than linux, and we cannot add them to the optionlist either, because there we don't know if we actually want to build MPI and it's also not strictly a linux-only optionlist.
Frank
Hello Erik, all,
Note that this has a straightforward work-around -- pass the respective options manually. This short before a release, I recommend going with a work-around instead of modifying Cactus's internal mechanism, which might break things.
Context: this affects the auto-build MPI library only, not the use of an existing MPI library found on a cluster or even the one found on ubuntu, debian, OSX etc. As far as I can see there is thus no way of "manually" specifying extra libraries (in an option list) since this only happens in exactly the case where the option list says "build yourself" or the auto-detection fails.
Frank already gave the answer as to where to modify things (it literally is) in his email:
$ENV{MPI_LIBS} .= " rt util" if($^O == "linux");
and as said rt and util as part of libc6 anyway so they are always present.
Yours, Roland
On Mon, Jun 19, 2017 at 11:18 AM, Roland Haas rhaas@illinois.edu wrote:
Hello Erik, all,
Note that this has a straightforward work-around -- pass the respective options manually. This short before a release, I recommend going with a work-around instead of modifying Cactus's internal mechanism, which might break things.
Context: this affects the auto-build MPI library only, not the use of an existing MPI library found on a cluster or even the one found on ubuntu, debian, OSX etc. As far as I can see there is thus no way of "manually" specifying extra libraries (in an option list)
You can modify the global LIBS variable.
-erik
since this only happens in exactly the case where the option list says "build yourself" or the auto-detection fails.
Frank already gave the answer as to where to modify things (it literally is) in his email:
$ENV{MPI_LIBS} .= " rt util" if($^O == "linux");
and as said rt and util as part of libc6 anyway so they are always present.
Yours, Roland
-- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://pgp.mit.edu .
Hello Erik,
You can modify the global LIBS variable.
I am not sure how to achieve this given that this must happen only on Linux and must work independently of simfactory.
Yours, Roland
On Mon, Jun 19, 2017 at 11:59 AM, Roland Haas rhaas@illinois.edu wrote:
Hello Erik,
You can modify the global LIBS variable.
I am not sure how to achieve this given that this must happen only on Linux and must work independently of simfactory.
I am viewing this as a work-around -- the user would set LIBS appropriately in their option list. I am not describing an automated mechanism here.
-erik
Yours,
Roland
-- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://pgp.mit.edu .
On Mon, Jun 19, 2017 at 12:04:44PM -0400, Erik Schnetter wrote:
I am viewing this as a work-around -- the user would set LIBS appropriately in their option list. I am not describing an automated mechanism here.
Doing these things by hand correctly always works. What I want is a workaround for the automation. This ought to work for something central as MPI and something wide-spread as Linux.
Frank
Hello all,
I guess one way to handle this would also be:
* add the LIBS=... workaround to the release notes * add the code to the master perl detect.pl script after the release as a bugfix (which it is) * wait a week for things to fail catastrophically * backport to release branch
Yours, Roland
On Mon, Jun 19, 2017 at 12:04:44PM -0400, Erik Schnetter wrote:
I am viewing this as a work-around -- the user would set LIBS >appropriately in their option list. I am not describing an automated >mechanism here.
Doing these things by hand correctly always works. What I want is a workaround for the automation. This ought to work for something central as MPI and something wide-spread as Linux.
Frank
On Mon, Jun 19, 2017 at 12:26:46PM -0500, Roland Haas wrote:
I guess one way to handle this would also be:
- add the LIBS=... workaround to the release notes
- add the code to the master perl detect.pl script after the release as
a bugfix (which it is)
- wait a week for things to fail catastrophically
- backport to release branch
It's one way of doing it. It would leave a majority of users with manual changes to their optionlist in simfactory, because the default isn't working. I don't want to go that way. If we do, I would vote to add those to LIBS already in simfactory, and add to the release notes that if you happen to use the debian (or also redhat I believe) optionlists on something else than Linux, you better remove those.
If we don't include the linux-query (perl) code in the release, I also think we shouldn't include at all, but instead properly fix the library list. We can query the library after it has been built. All we need to do is to make it possible to tell Cactus about those.
Frank
Hello Frank,
It's one way of doing it. It would leave a majority of users with manual changes to their optionlist in simfactory, because the default isn't working.
I wouldn't say that. I would hope that the majority of users does not have to build OpenMPI from scratch. Mostly because that only barely works (eg does not put mpirun into PATH so that simfactory's run scripts do not work).
I don't want to go that way. If we do, I would vote to add those to LIBS already in simfactory, and add to the release notes that if you happen to use the debian (or also redhat I believe) optionlists on something else than Linux, you better remove those.
I thought this must work without simfactory? Adding them to the SF files is of course an option (obviously only the ones for Linux).
If we don't include the linux-query (perl) code in the release, I also think we shouldn't include at all, but instead properly fix the library list. We can query the library after it has been built. All we need to do is to make it possible to tell Cactus about those.
I would include it. I don't expect the Cactus build system to be re-written anytime soon (because there are pressing issues that eg prevent us from running on Stampede so no one can use their allocation on one of the few remaining US resources). Also we already have may open issues with the ExternalLibraries and their build scripts. It would be good to close some of those first before we open up new issues.
Yours, Roland
On Mon, Jun 19, 2017 at 02:19:24PM -0500, Roland Haas wrote:
I wouldn't say that. I would hope that the majority of users does not have to build OpenMPI from scratch. Mostly because that only barely works (eg does not put mpirun into PATH so that simfactory's run scripts do not work).
True enough.
I don't want to go that way. If we do, I would vote to add those to LIBS already in simfactory, and add to the release notes that if you happen to use the debian (or also redhat I believe) optionlists on something else than Linux, you better remove those.
I thought this must work without simfactory? Adding them to the SF files is of course an option (obviously only the ones for Linux).
Yes, it should work without simfactory, but I would vote to do this, for those that are most likely going to be use for Linux. So, we must mention this in any case, but can say that if you happen to use one of those (pretty likely, even if not using simfactory itself), then this already has been done for you.
If we don't include the linux-query (perl) code in the release, I also think we shouldn't include at all, but instead properly fix the library list. We can query the library after it has been built. All we need to do is to make it possible to tell Cactus about those.
I would include it. I don't expect the Cactus build system to be re-written anytime soon (because there are pressing issues that eg prevent us from running on Stampede so no one can use their allocation on one of the few remaining US resources).
True. On this topic: who of those that actually want to use their allocation on stampede is actively working on this problem?
Also we already have may open issues with the ExternalLibraries and their build scripts. It would be good to close some of those first before we open up new issues.
Some of those could be solved by this. Wasn't there at least one other library that potentially, but not always, pulled in other dependencies?
I don't disagree about the amount of work and also not about the not very high priority though.
Frank
users@lists.einsteintoolkit.org
-
Erik Schnetter -
Frank Loeffler -
Roland Haas