Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PRRTE build failure with GCC 14.2.1 on Fedora 40 #12881

Open
dalcinl opened this issue Oct 24, 2024 · 8 comments
Open

PRRTE build failure with GCC 14.2.1 on Fedora 40 #12881

dalcinl opened this issue Oct 24, 2024 · 8 comments

Comments

@dalcinl
Copy link
Contributor

dalcinl commented Oct 24, 2024

This is with ompi@main

../../../../../ompi-main/3rd-party/prrte/src/prted/pmix/pmix_server_queries.c: In function '_query':
../../../../../ompi-main/3rd-party/prrte/src/prted/pmix/pmix_server_queries.c:837:71: error: passing argument 5 of 'PMIx_Get' from incompatible pointer type [-Wincompatible-pointer-types]
  837 |                 ret = PMIx_Get(&pproc, PMIX_MEM_ALLOC_KIND, &info, 1, (void**)&value);
      |                                                                       ^~~~~~~~~~~~~~
      |                                                                       |
      |                                                                       void **
In file included from /home/dalcinl/Devel/REPOS/ompi-main/3rd-party/openpmix/src/util/pmix_error.h:26,
                 from /home/dalcinl/Devel/REPOS/ompi-main/3rd-party/prrte/src/pmix/pmix-internal.h:32,
                 from ../../../../../ompi-main/3rd-party/prrte/src/prted/pmix/pmix_server_queries.c:40:
/home/dalcinl/Devel/REPOS/ompi-main/3rd-party/openpmix/include/pmix.h:208:51: note: expected 'pmix_value_t **' {aka 'struct pmix_value **'} but argument is of type 'void **'
  208 |                                    pmix_value_t **val);
      |                                    ~~~~~~~~~~~~~~~^~~

cc @rhc54

@dalcinl dalcinl changed the title PRRTE build failure with GCC 14.2.1 on Fedora 30 PRRTE build failure with GCC 14.2.1 on Fedora 40 Oct 24, 2024
@rhc54
Copy link
Contributor

rhc54 commented Oct 24, 2024

Afraid that has nothing to do with me - it's a bug in the OMPI fork of PRRTE, not present in PRRTE itself. FWIW: we've seen some oddities in gcc 14.2, so it may not always be generating true issues. Not saying this one is in that category - just noting for future reference.

@bosilca
Copy link
Member

bosilca commented Oct 24, 2024

@dalcinl openpmix/prrte#1976

@dalcinl
Copy link
Contributor Author

dalcinl commented Oct 24, 2024

Sorry, but I need a small clarification to avoid confusion in future interactions.

If I do

$grep url .git/modules/*/config | grep -v [email protected]:open-mpi
.git/modules/openpmix/config:	url = [email protected]:openpmix/openpmix.git
.git/modules/prrte/config:	url = [email protected]:openpmix/prrte

it looks like both the openmpix and prrte submodules track the respective upstream repositories, and not forks within the open-mpi organization.
Is this correct or am I missing something?

In any case, thanks for the prompt fix. I'll wait until the submodule pointer gets updated.

@rhc54
Copy link
Contributor

rhc54 commented Oct 24, 2024

Hmmm...I'm pretty sure that isn't correct for OMPI main. I believe they pointed the PRRTE submodule at open-mpi/prrte, which is their fork. Unfortunately, the two aren't tracking very well. For example, that fix was committed upstream in early May!

Note that the OMPI v5 branch does still point at upstream PRRTE, which may be what your little grep is hitting.

@dalcinl
Copy link
Contributor Author

dalcinl commented Oct 24, 2024

OK, thanks for the clarification. My ompi@main clone is definitely still using the upstream prrte remote. I've been using git worktrees for checking out main/v5.0.x/v4.0x, I guess that worktrees do not play well with submodule URLs.

PS: @bosilca @jsquyres If that is the case, that is, mixing git worktrees with git submodules is somewhat broken, then this issue may hit other easily, I think savvy git users use worktrees a lot. Perhaps the OMPI and PRRTE devs can negotiate a branch namespace on upstream PRRT (eg. have branches ompi/main and ompi/v5.0.x in the upstream PRRTE git repository) such that you can put there your commits to track as git submodules in the OMPI repository. That way, when switching OMPI branches (or checking out branches in other worktress), the remote URLs for submodules do not change.

@rhc54
Copy link
Contributor

rhc54 commented Oct 24, 2024

My ompi@main clone is definitely still using the upstream prrte remote

The bug you reported above only exists in the OMPI fork. Unless you haven't updated since May 7, you must be looking at the OMPI fork.

@dalcinl
Copy link
Contributor Author

dalcinl commented Oct 25, 2024

OK, I definitely messed up, I never run git submodule sync to update the submodule remote URL, so that was what confused me.

@bosilca Is there any plain to cherry-pick openpmix/prrte#1976 into the open-mpi/prrte fork and update the submodule pointer?

@bosilca
Copy link
Member

bosilca commented Oct 25, 2024

open-mpi/prrte#48

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants