Tests fail on openSUSE (any version), I assume it needs LD_LIBRARY_PATH set at some point, but I don't know cmake enough to fix it myself.
Hi Luigi:
To get further with this I need more details. To supply those, please do the following
In an initially empty build tree:
cmake -DBUILD_SHARED_LIBS=ON <path to lasi source tree> >& cmake.out
make VERBOSE=1 all >& all.out
ctest --extra-verbose >& ctest.out
Collect the file CMakeCache.txt (generated by cmake in the top of the build tree), and cmake.out, all.out, and ctest.out into a tarball and attach that to the bug report.
I am pretty sure doing the tests this way should "just work" for you
since it does for me, and CMake should automatically take care of all
rpath details in the build tree regardless of platform. But let's
establish that first before trying to figure out what went wrong for
your own test.
Alan
Alan W. Irwin
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
Linux-powered Science
Last edit: Alan W. Irwin 2019-06-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately I could not understand how to pass that XML tag to cmake.
It is not an XML tag. And it was further clobbered by some markdown translation that was going on from my original e-mail content to what is rendered at SourceForge.
The brackets notation simply means in this case it is a description of the option you should have there in the command line.
So (trying backtick notation this time to attempt to stop markdown translation)
<path to top-level directory of source tree>
should be replaced literally by "/home/baldoni/lasi.git", "..", "../lasi.git", or whatever is appropriate in your case for the absolute path of that top-level directory or the relative path of that same directory from an initially empty build tree.
But since you did not specify that path, CMake forced you to cd to the
top level of the source tree before building which is a really bad
fallback option which you should avoid since it completely messes up
(overwriting important files) what should be a pristine source tree.
For example, that messing up of the source tree could be the cause of the segfault that
was the initial error occurring in the "obs" case.
So please recreate a pristine source tree from svn and never build
in its top-level directory. Instead, in all cases it is important to
create an initially empty directory and cd to that empty directory before
you invoke cmake with a specified absolute or relative path that gives
the location of the top-level directory of the source tree.
So once I have 1.1.4 finalized from my perspective (i.e.,
it passes all my tests including valgrind ones of the example creation that
segfaulted in your case) please try the two experiments again where in both cases
you invoke cmake from an initially empty build tree with top-level-directory of
the pristine source tree specified.
Alan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
But now that I have had a chance to work on libLASi again could you please try revision 233? In particular, could you follow the new instructions in section (1) of README.Release_Manager_Cookbook for preliminary testing of libLASi? In your case don't bother with the PLplot part of the test (which happens automatically with this new test_tarball.sh script if you don't specify PLplot-related environment variables).
I just now ran test_tarball.sh for our four different configurations for CMake-3.13.2 (our minimum allowed CMake version) with perfect results (including the special external PLplot comprehensive test that is designed to test libLASi in a large number of different ways) on Debian Buster. So I hope it is possible for you to do the same there (but without the external PLplot component of the test and with the first argument of the script specified as "/usr/bin" so that you simply test with your system version of CMake.
That is, you should build a source tarball by configuring the libLASi build as normal in an initially empty build tree, then run
make all
make package_source
which should create libLASi-1.1.3.tar.gz in the build tree. (That version is currently 1.1.3 because I have not yet made version changes for the forthcoming 1.1.4 release, but the contents of that tarball should be quite close to what 1.1.4 will be.) Then test that source tarball by
export LASI_VERSION=1.1.3
# I use -j16 since I have 16 hardware threads on my computer, but adjust
# that number appropriately for your own hardware
export PARALLEL_OPTION=-j16
./test_tarball.sh /usr/bin -DBUILD_SHARED_LIBS=ON -DNON_TRANSITIVE=ON
./test_tarball.sh /usr/bin -DBUILD_SHARED_LIBS=ON -DNON_TRANSITIVE=OFF
./test_tarball.sh /usr/bin -DBUILD_SHARED_LIBS=OFF -DPREFER_EXTERNAL_STATIC=OFF
./test_tarball.sh /usr/bin -DBUILD_SHARED_LIBS=OFF -DPREFER_EXTERNAL_STATIC=ON
N.B. for this test script to work properly, at least the pqiv, inkscape, and valgrind commands need to be installed and likely a few more which the script will tell you about if some command needed by the script is not installed on your system.
Good luck with these tests, and let me know how it goes.
Last edit: Alan W. Irwin 2019-07-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am changing the status of this bug report to closed-fixed since all my extensive testing on Debian Buster indicates that is the case. And I have decided to move ahead with the forthcoming release of 1.1.4 in the next few days based on this bug fix (and several other less important bug fixes). However, if you do have time to test revision 233 in exactly the way I indicated in the next few days, that should provide helpful confirmation for the release that this linking bug is now gone on all Linux platforms.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On 2019-06-07 06:24-0000 Luigi Baldoni wrote:
Hi Luigi:
To get further with this I need more details. To supply those, please do the following
In an initially empty build tree:
cmake -DBUILD_SHARED_LIBS=ON <path to lasi source tree> >& cmake.outmake VERBOSE=1 all >& all.out
ctest --extra-verbose >& ctest.out
Collect the file CMakeCache.txt (generated by cmake in the top of the build tree), and cmake.out, all.out, and ctest.out into a tarball and attach that to the bug report.
I am pretty sure doing the tests this way should "just work" for you
since it does for me, and CMake should automatically take care of all
rpath details in the build tree regardless of platform. But let's
establish that first before trying to figure out what went wrong for
your own test.
Alan
Alan W. Irwin
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
Linux-powered Science
Last edit: Alan W. Irwin 2019-06-08
Unfortunately I could not understand how to pass that XML tag to cmake.
These are the commands I issued:
As you predicted, it worked perfectly in a local tree, however I still see the original problem in the chroot openSUSE OBS uses for building rpms.
I'm including both sets of logs in the attached tarball.
Last edit: Luigi Baldoni 2019-06-07
On 2019-06-07 23:17-0000 Luigi Baldoni wrote:
It is not an XML tag. And it was further clobbered by some markdown translation that was going on from my original e-mail content to what is rendered at SourceForge.
The brackets notation simply means in this case it is a description of the option you should have there in the command line.
So (trying backtick notation this time to attempt to stop markdown translation)
<path to top-level directory of source tree>should be replaced literally by "/home/baldoni/lasi.git", "..", "../lasi.git", or whatever is appropriate in your case for the absolute path of that top-level directory or the relative path of that same directory from an initially empty build tree.
But since you did not specify that path, CMake forced you to cd to the
top level of the source tree before building which is a really bad
fallback option which you should avoid since it completely messes up
(overwriting important files) what should be a pristine source tree.
For example, that messing up of the source tree could be the cause of the segfault that
was the initial error occurring in the "obs" case.
So please recreate a pristine source tree from svn and never build
in its top-level directory. Instead, in all cases it is important to
create an initially empty directory and cd to that empty directory before
you invoke cmake with a specified absolute or relative path that gives
the location of the top-level directory of the source tree.
So once I have 1.1.4 finalized from my perspective (i.e.,
it passes all my tests including valgrind ones of the example creation that
segfaulted in your case) please try the two experiments again where in both cases
you invoke cmake from an initially empty build tree with top-level-directory of
the pristine source tree specified.
Alan
Done on r230 svn.
I ran the crashing program through gdb, not sure what to make of it, please see attached log.
Sorry for the delay in getting back to you.
But now that I have had a chance to work on libLASi again could you please try revision 233? In particular, could you follow the new instructions in section (1) of README.Release_Manager_Cookbook for preliminary testing of libLASi? In your case don't bother with the PLplot part of the test (which happens automatically with this new test_tarball.sh script if you don't specify PLplot-related environment variables).
I just now ran test_tarball.sh for our four different configurations for CMake-3.13.2 (our minimum allowed CMake version) with perfect results (including the special external PLplot comprehensive test that is designed to test libLASi in a large number of different ways) on Debian Buster. So I hope it is possible for you to do the same there (but without the external PLplot component of the test and with the first argument of the script specified as "/usr/bin" so that you simply test with your system version of CMake.
That is, you should build a source tarball by configuring the libLASi build as normal in an initially empty build tree, then run
which should create libLASi-1.1.3.tar.gz in the build tree. (That version is currently 1.1.3 because I have not yet made version changes for the forthcoming 1.1.4 release, but the contents of that tarball should be quite close to what 1.1.4 will be.) Then test that source tarball by
N.B. for this test script to work properly, at least the pqiv, inkscape, and valgrind commands need to be installed and likely a few more which the script will tell you about if some command needed by the script is not installed on your system.
Good luck with these tests, and let me know how it goes.
Last edit: Alan W. Irwin 2019-07-10
I am changing the status of this bug report to closed-fixed since all my extensive testing on Debian Buster indicates that is the case. And I have decided to move ahead with the forthcoming release of 1.1.4 in the next few days based on this bug fix (and several other less important bug fixes). However, if you do have time to test revision 233 in exactly the way I indicated in the next few days, that should provide helpful confirmation for the release that this linking bug is now gone on all Linux platforms.