Philipp,
You are right that libtool doesn't need to put "/usr/lib64/libltdl.so" in
the compiler command line as the *only* solution. I only meant that doing
so was preferred over the observed behavior of putting the full path of a
library for the wrong architecture. You are correct that passing
Hi Paul,
sorry for chiming in so late, but this list is on low priority for me at the
moment.
* Paul Hargrove (phhargr...@lbl.gov) [20150202 22:58]:
> is erroneous is that /usr/lib contains 32-bit libs (and target is 64-bit).
> Therefore libtool should have replaced -lltdl with /usr/lib64/libltdl
On Mon, Feb 2, 2015 at 9:26 PM, Paul Hargrove wrote:
> I am now going to see about a PGI compiler on a system at another center
> (or two?) in order to see how universal the problem is.
That was a dead-end.
Of the many non-NERSC non-Cray institutions where I have accounts, I could
only find on
On Mon, Feb 2, 2015 at 5:47 PM, Paul Hargrove wrote:
> I'll report my test results more completely later, but all 4 PGI-based
> builds I have results for so far have failed with libtool replacing
> "-lltdl" in link command line with "/usr/lib/libltdl.so" rather than the
> correct "/usr/lib64/lib
On Mon, Feb 2, 2015 at 5:22 PM, Paul Hargrove wrote:
> So, the overhead for me is pretty small as long as the number of failures
> is kept low.
I jinxed it!!!
I have, I believe, about 7 different failures now on various systems.
All of those appear UNRELATED to the libltdl changes.
I went ahe
On Mon, Feb 2, 2015 at 4:13 PM, Paul Hargrove wrote:
> HOWEVER - switching from PGI to GNU compilers made the problem go away.
> So, I suspect it may be an issue with the installation/configuration of
> the PGI compilers.
>
I've reproduced the problem on a non-Cray system with four different
in
Jeff,
Having already pointed my script at your tarball's URL, typing
"./test-ompi" releases about 60 "hounds". I get an email for each system
as it's tests complete, and gmail filters tag only the ones where one or
more configurations failed. So, the overhead for me is pretty small as
long as th
Paul --
If you've got the cycles and it's easy, release the hounds on the tarball that
I just uploaded to:
http://www.open-mpi.org/~jsquyres/unofficial/
Thanks!
> On Feb 2, 2015, at 7:19 PM, Paul Hargrove wrote:
>
> Jeff,
>
> If you are still chasing the goal of getting this branch to
Jeff,
If you are still chasing the goal of getting this branch to "just work",
then I am willing to keep testing. Let me know when a new tarball is ready
and I'll give it a run on all of my systems.
-Paul
On Mon, Feb 2, 2015 at 4:15 PM, Jeff Squyres (jsquyres)
wrote:
> I had fixed it in my lo
I had fixed it in my local tree but not yet pushed to my github branch; I was
waiting to see what happened w.r.t. your failure on the NERSC machine.
I pushed the fix up to my branch now; do you want a new tarball?
> On Feb 2, 2015, at 5:56 PM, Paul Hargrove wrote:
>
> Jeff,
>
> Looks like yo
On Mon, Feb 2, 2015 at 1:58 PM, Paul Hargrove wrote:
> 2b. I am retrying now with all of Cray's environment modules unloaded
> except the one for the PGI compiler. Nathan had suggested something like
> this to me in the past, but I've never had issues with the default
> environment. I will rep
Jeff,
Looks like you didn't hit all the un-guarded references to lt_dladvise.
Specifically you missed a struct decl:
/[]/openmpi-libltdl-linux-x86_64-gcc/openmpi-gitclone/opal/util/lt_interface.c:25:8:
error: unknown type name 'lt_dladvise'
-Paul
On Sat, Jan 31, 2015 at 4:44 AM, Jeff Squyr
On 03/02/15 05:09, Ralph Castain wrote:
> Just out of curiosity: I see you are reporting about a build on the
> headnode of a BG cluster. We've never ported OMPI to BG - are you using
> it on such a system? Or were you just test building the code on a
> convenient server?
Just a convenient server
On Feb 2, 2015, at 5:24 PM, Jeff Squyres (jsquyres) wrote:
>
> IANAL, but after talking through the license stuff, we think there will be
> new license issues caused by --disable-dlopen behavior.
ARRGH -- that should have been:
...we think there will be ***NO*** new license issues caused by
-
Ralph and I just chatted about this on the phone.
IANAL, but after talking through the license stuff, we think there will be new
license issues caused by --disable-dlopen behavior.
It feels like there's a lot of unexpected issues coming up with (more-or-less)
causing (most?) people to build wit
Jeff and Howard,
Just a couple minor points:
1. In case one has lost track, the reason the behavior described by Jeff
is erroneous is that /usr/lib contains 32-bit libs (and target is 64-bit).
Therefore libtool should have replaced -lltdl with /usr/lib64/libltdl.so
(if at all).
2a. Jeff does r
Re-adding devel, since Paul sent me the logs off-list.
(per Ralph's comment, we may or may not stick with this don't-build-libltdl
philosophy, but I'd still like to run this issue down)
Howard: see Paul's notes below. It's on the hopper system at Nersc.
Do you have any Cray insight here? (see
Uuuurggghhh.
More below.
> On Feb 2, 2015, at 1:04 PM, Ralph Castain wrote:
>
> Returning to the libltdl question: I think we may have a problem here. If we
> remove libltdl and default to disable-dlopen, then the user will - without
> warning - slurp all components that are able to build in
Hi Chris
Just out of curiosity: I see you are reporting about a build on the
headnode of a BG cluster. We've never ported OMPI to BG - are you using it
on such a system? Or were you just test building the code on a convenient
server?
Ralph
On Mon, Feb 2, 2015 at 3:52 AM, Chris Samuel wrote:
>
Returning to the libltdl question: I think we may have a problem here. If
we remove libltdl and default to disable-dlopen, then the user will -
without warning - slurp all components that are able to build into libompi.
This includes everything they specified, BUT because of our "build if you
can"
On Mon, 2 Feb 2015 11:35:40 AM Jeff Squyres wrote:
> Ah -- the point being that this is not an issue related to the libltdl work.
Sorry - I saw the request to test the tarball and tried it out, missed the
significance of the subject. :-/
--
Christopher SamuelSenior Systems Administrat
Ah -- the point being that this is not an issue related to the libltdl work.
> On Feb 2, 2015, at 2:51 AM, Adrian Reber wrote:
>
> I have reported the same error a few days ago and submitted it now as a
> github issue: https://github.com/open-mpi/ompi/issues/371
>
> On Mon, Feb 02, 2015 at 12:
I have reported the same error a few days ago and submitted it now as a
github issue: https://github.com/open-mpi/ompi/issues/371
On Mon, Feb 02, 2015 at 12:36:54PM +1100, Christopher Samuel wrote:
> On 31/01/15 10:51, Jeff Squyres (jsquyres) wrote:
>
> > New tarball posted (same location). Now
On 31/01/15 10:51, Jeff Squyres (jsquyres) wrote:
> New tarball posted (same location). Now featuring 100% fewer "make check"
> failures.
On our BG/Q front-end node (PPC64, RHEL 6.4) I see:
../../config/test-driver: line 95: 30173 Segmentation fault (core dumped)
"$@" > $log_file 2>&1
FA
Hmm.
I'm unable to find where this happens -- we don't explicitly list "libltdl.so"
anywhere, for example. Libltdl is added by AC_CHECK_LIB, like most other
libraries OMPI links against.
Can you send more info (perhaps off-list, if the attachments get large):
- full output of configure
- conf
Looks like the lt_interface.c code didn't properly use the lt_dladvise #if. How
did that ever work, I wonder?
Fixed now. On to your second finding...
> On Jan 30, 2015, at 7:42 PM, Paul Hargrove wrote:
>
> Not meeting with the greatest of success.
> This is a report of just the first (of at
Observed failure mode 2-of-2:
On at least one SLES-11.1 system you are attempting to link libltdl.so by
full path and are erroneously using /usr/lib/libltdl.so instead of
/usr/lib64/libltdl.so, resulting in the failure below.
-Paul
libtool: link: pgcc -shared -fpic -DPIC class/.libs/opal_bitma
Not meeting with the greatest of success.
This is a report of just the first (of at least 2) failure modes I am
seeing.
On a Scientific Linux 5.5. (RHEL-5.5 clone like CentOS) I get a build
failure described below.
At least Solaris-11 and a few other linux systems (including RHAS-4.4) are
also fai
New tarball posted (same location). Now featuring 100% fewer "make check"
failures.
http://www.open-mpi.org/~jsquyres/unofficial/
> On Jan 30, 2015, at 5:14 PM, Jeff Squyres (jsquyres)
> wrote:
>
> Shame on me for not running "make check".
>
> Fixing...
>
>
>> On Jan 30, 2015, at 4:5
Shame on me for not running "make check".
Fixing...
> On Jan 30, 2015, at 4:58 PM, Paul Hargrove wrote:
>
> Jeff,
>
> I ran on just one (mac OSX 10.8) system first as a "smoke test".
> It encountered the failure show below on "make check" at which point I
> decided not to test 60+ platforms.
Jeff,
I ran on just one (mac OSX 10.8) system first as a "smoke test".
It encountered the failure show below on "make check" at which point I
decided not to test 60+ platforms.
Please advise how I should proceed (best guess is wait for a new tarball).
-Paul
Making check in test
Making check in s
On Jan 30, 2015, at 2:46 PM, Paul Hargrove wrote:
>
> If I had new enough autotools to autogen on this old system then I wouldn't
> have asked about libltdl from libtool-1.4. So, please *do* generate a
> tarball and I will test (on *all* of my systems).
Sweet, thank you. I just posted a tarb
Jeff,
Thanks for the lengthy explanation.
I now understand the situation *much* better.
Some portion of your response could become an FAQ for v1.9.
Regarding:
> Would you mind testing the OMPI PR branch on this old system? I can make
> you a tarball if it would help.
If I had new enough autot
On Jan 29, 2015, at 9:11 PM, Paul Hargrove wrote:
>
> If I understand one is (or will be soon) expected to have libtool-dev(el)
> installed on the build system, even if one is not a OMPI developer.
No. We don't want to raise the bar that high for simple user installations.
If you are installi
Jeff,
If I understand one is (or will be soon) expected to have libtool-dev(el)
installed on the build system, even if one is not a OMPI developer.
How does this plan to cease embedding libltdl align with the fact that
autogen.pl currently applies patches to the parts of the generated
configure f
35 matches
Mail list logo
