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.

Sign up for GitHub

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

Jump to bottom

OMPI build broken on OpenBSD #7

Closed
ompiteam opened this issue Oct 1, 2014 · 14 comments
Closed

OMPI build broken on OpenBSD #7

ompiteam opened this issue Oct 1, 2014 · 14 comments
Assignees
@ompiteam
Labels
bug Severity: minor
Milestone
Future

Comments

@ompiteam
Copy link
Contributor

ompiteam commented Oct 1, 2014

Neither the 1.1.1 release nor the 1.2 branch can be built on OpenBSD (3.9).

 gcc -DHAVE_CONFIG_H -I. -I. -I../../opal/include -I../../orte/include -I../../ompi/include -I../../ompi/include -I../.. -O3 -DNDEBUG -fno-strict-aliasing -pthread -MT stacktrace.lo -MD -MP -MF .deps/stacktrace.Tpo -c stacktrace.c  -fPIC -DPIC -o .libs/stacktrace.o
stacktrace.c: In function `opal_show_stackframe':
stacktrace.c:232: error: `SI_ASYNCIO' undeclared (first use in this function)
stacktrace.c:232: error: (Each undeclared identifier is reported only once
stacktrace.c:232: error: for each function it appears in.)
stacktrace.c:233: error: `SI_MESGQ' undeclared (first use in this function)
gmake[3]: *** [stacktrace.lo] Error 1
gmake[3]: Leaving directory `/var/tmp/openmpi-1.1.1/opal/util'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory `/var/tmp/openmpi-1.1.1/opal/util'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/var/tmp/openmpi-1.1.1/opal'
gmake: *** [all-recursive] Error 1

I can't imagine why one would use OpenBSD for high performance computing (think of the poor OpenBSD performance in general), so we might close this ticket with "wontfix". (just wanted to let you know...)
@ompiteam ompiteam self-assigned this Oct 1, 2014
@ompiteam ompiteam added this to the Future milestone Oct 1, 2014
@ompiteam
Copy link
Contributor Author

ompiteam commented Oct 1, 2014

Imported from trac issue 393. Created by adi on 2006-09-21T18:15:50, last modified: 2007-10-22T10:10:55

@ompiteam
Copy link
Contributor Author

ompiteam commented Oct 1, 2014

Trac comment by jsquyres on 2006-09-22 06:06:25:

I'm guessing that this is simply because stacktrace was not adapted for OpenBSD.

FWIW, on the trunk (i.e., someday to be v1.3), stacktrace was adapted to be an MCA framework (opal/backtrace), so it'll be easier to fix there.

Unless there's a screaming need, I'd prefer to fix this only on the trunk (i.e., in the framework).

@ompiteam
Copy link
Contributor Author

ompiteam commented Oct 1, 2014

Trac comment by brbarret on 2006-09-22 09:51:57:

Anyone have an OpenBSD box I can have access to? This should be a fairly trivial fix...

@ompiteam
Copy link
Contributor Author

ompiteam commented Oct 1, 2014

Trac comment by brbarret on 2006-09-22 15:50:13:

Can you try the attached patch and see if it helps.

By the way, this is in the general "what caused the signal" code, not the stacktrace code. So this will be the same patch for all three branches.

@ompiteam
Copy link
Contributor Author

ompiteam commented Oct 1, 2014

Trac comment by adi on 2006-09-23 15:19:34:

The patch works fine, but now another error occurs:

-DHAVE_ROMIOCONF_H -DHAVE_ROMIOCONF_H -I../../include -MT io_romio_ad_fstype.lo -MD -MP -MF .deps/io_romio_ad_fstype.Tpo -c io_romio_ad_fstype.c  -fPIC -DPIC -o .libs/io_romio_ad_fstype.o
io_romio_ad_fstype.c: In function `mca_io_romio_dist_ADIO_FileSysType_fncall':
io_romio_ad_fstype.c:305: error: structure has no member named `f_type'
io_romio_ad_fstype.c:319: error: structure has no member named `f_type'
gmake[6]: *** [io_romio_ad_fstype.lo] Error 1
gmake[6]: Leaving directory `/var/tmp/trunk/build/OpenBSD-i386/ompi/mca/io/romio/romio/adio/common'
gmake[5]: *** [install-recursive] Error 1
gmake[5]: Leaving directory `/var/tmp/trunk/build/OpenBSD-i386/ompi/mca/io/romio/romio/adio'
gmake[4]: *** [install-recursive] Error 1
gmake[4]: Leaving directory `/var/tmp/trunk/build/OpenBSD-i386/ompi/mca/io/romio/romio'
gmake[3]: *** [install-recursive] Error 1
gmake[3]: Leaving directory `/var/tmp/trunk/build/OpenBSD-i386/ompi/mca/io/romio'
gmake[2]: *** [install-recursive] Error 1
gmake[2]: Leaving directory `/var/tmp/trunk/build/OpenBSD-i386/ompi'
gmake[1]: *** [install-recursive] Error 1
gmake[1]: Leaving directory `/var/tmp/trunk/build/OpenBSD-i386'
gmake: *** [/var/tmp/trunk/OpenBSD-i386] Error 2

@ompiteam
Copy link
Contributor Author

ompiteam commented Oct 1, 2014

Trac comment by brbarret on 2006-09-24 14:21:22:

(In [11770]) OpenBSD doesn't define some constants that other OSes do.

refs https://svn.open-mpi.org/trac/ompi/ticket/393

@ompiteam
Copy link
Contributor Author

ompiteam commented Oct 1, 2014

Trac comment by brbarret on 2006-09-24 14:22:30:

That's an odd error. I'd have to work at that one a bit to figure out what is going on. Since I don't have access to an OpenBSD system, unassigning it from me.

@ompiteam
Copy link
Contributor Author

ompiteam commented Oct 1, 2014

Trac comment by jsquyres on 2007-03-20 15:25:45:

This will never get fixed in the 1.1 series. Moving to 1.2.x; that's the earliest hope that it may get fixed (if anyone cares...).

@ompiteam
Copy link
Contributor Author

ompiteam commented Oct 1, 2014

Trac comment by jsquyres on 2007-10-22 09:42:30:

This patch was applied to the trunk in r11770. I'm assuming it fixed the problem since we didn't hear any more about it, so I'm closing this ticket.

@ompiteam
Copy link
Contributor Author

ompiteam commented Oct 1, 2014

Trac comment by adi on 2007-10-22 09:47:04:

I guess it's not fixed, but I don't care as long as nobody wants us to have OMPI on OpenBSD. If need be, I could set up another virtual box for OpenBSD (as it has been done for kFreeBSD), create a patch and apply it.

For now, I don't see anybody doing HPC with OpenBSD (poor performance from the last time I saw it).

@ompiteam
Copy link
Contributor Author

ompiteam commented Oct 1, 2014

Trac comment by jsquyres on 2007-10-22 09:48:20:

Are you sure it's not fixed (on the trunk)? I don't know / didn't check to see if it was brought over to the v1.2 release branch.

@ompiteam
Copy link
Contributor Author

ompiteam commented Oct 1, 2014

Trac comment by adi on 2007-10-22 09:55:49:

Replying to [comment:15 jsquyres]:

Are you sure it's not fixed (on the trunk)? I don't know / didn't check to see if it was brought over to the v1.2 release branch.

r11770 is the trivial fix for some missing constants, but see [comment:6] for the missing f_type. AFAIK, nobody has ever investigated on this.

I'm not completely sure if it's fixed or not, I tend to deny, but we'll have to check it on OpenBSD to prove it. As already mentioned: I'm not very keen in doing so, but if you want to include "OMPI now supports OpenBSD" in the next release, I'll do it.

@ompiteam
Copy link
Contributor Author

ompiteam commented Oct 1, 2014

Trac comment by jsquyres on 2007-10-22 10:10:20:

Ah, I see -- I missed the f_type comment. I'll re-open and put into the "future" category so that the information is not lost. I have no immediate desire to support OpenBSD.

This is really a ROMIO issue, BTW -- has anyone notified the ROMIO authors? (it also rings a very, very distant bell for an old ROMIO / BSD issue about something broken in a configure test... perhaps something we patched/fixed in LAM/MPI long, long ago...?)

rhc54 pushed a commit that referenced this issue Oct 31, 2014
Merge pull request #7 from miked-mellanox/topic/oshmem_add_two_new_mc…
da1cdd7 
…a_variables

Add-two-new-mca-variables, fix opal_help failure
@hjelmn
Copy link
Member

hjelmn commented Feb 17, 2015

master appears to build and run fine on OpenBSD 5.6 despite the fact that the platform is not supported by hwloc.

Also, Open MPI 1.4.1 is available as an OpenBSD package.

Guessing this was long since fixed. Probably should close it.

yosefe pushed a commit to yosefe/ompi that referenced this issue Mar 5, 2015
@mike-dubman
Merge pull request open-mpi#7 from mellanox-hpc/topic/sync_with_ompi_…
8cfb07f 
…v1.8

sync with ompi-release/v1.8
@opoplawski opoplawski mentioned this issue Mar 16, 2015
Open
lrrajesh pushed a commit to lrrajesh/ompi that referenced this issue Mar 19, 2015
Merge pull request open-mpi#7 from lrrajesh/master
aace861 
klocwork, help file changes and segfault issue resolved in job launch code.
@sjeaugey sjeaugey mentioned this issue Dec 11, 2015
Closed
@matcabral matcabral mentioned this issue Jan 19, 2016
Closed
@rhc54 rhc54 mentioned this issue Mar 26, 2016
Merged
@bosilca bosilca mentioned this issue Sep 26, 2016
Closed
bosilca referenced this issue in bosilca/ompi Oct 3, 2016
@bosilca
Per the discussion on the telecon, change the -host behavior so we on…
4b0cccb 
…ly run one instance if no slots were provided and the user didn't specify #procs to run. However, if no slots are given and the user does specify #procs, then let the number of slots default to the #found processing elements

Ensure the returned exit status is non-zero if we fail to map

If no -np is given, but either -host and/or -hostfile was given, then error out with a message telling the user that this combination is not supported.

If -np is given, and -host is given with only one instance of each host, then default the #slots to the detected #pe's and enforce oversubscription rules.

If -np is given, and -host is given with more than one instance of a given host, then set the #slots for that host to the number of times it was given and enforce oversubscription rules. Alternatively, the #slots can be specified via "-host foo:N". I therefore believe that row #7 on Jeff's spreadsheet is incorrect.

With that one correction, this now passes all the given use-cases on that spreadsheet.

Make things behave under unmanaged allocations more like their managed cousins - if the #slots is given, then no-np shall fill things up.

Fixes open-mpi#1344
Closed
Closed
@sbasavapatna sbasavapatna mentioned this issue Apr 19, 2017
Closed
@junjieqian junjieqian mentioned this issue May 4, 2017
Closed
@awlauria awlauria mentioned this issue Aug 30, 2017
Closed
@xavier1arm xavier1arm mentioned this issue Sep 13, 2017
Closed
@npe9 npe9 mentioned this issue Oct 13, 2017
Closed
ggouaillardet pushed a commit to ggouaillardet/ompi that referenced this issue Jan 13, 2018
Merge pull request open-mpi#7 from rhc54/topic/update
40ce261 
Sync with OMPI master
@sam6258 sam6258 mentioned this issue Feb 21, 2018
Open
@LiweiPeng LiweiPeng mentioned this issue Jul 25, 2018
Closed
@amckinstry amckinstry mentioned this issue Oct 4, 2018
Merged
artpol84 referenced this issue in artpol84/ompi Nov 13, 2018
@xinzhao3
Merge pull request #7 from artpol84/osc/mt_v2
ccfb889 
Intermediate fixes
@hjelmn hjelmn mentioned this issue Jan 15, 2019
Closed
@iassiour iassiour mentioned this issue Apr 24, 2019
Closed
@mwheinz mwheinz mentioned this issue Jul 26, 2019
Closed
@cagoelz cagoelz mentioned this issue Apr 15, 2020
Closed
@iassiour iassiour mentioned this issue Jun 5, 2020
Closed
shizhibao pushed a commit to shizhibao/ompi that referenced this issue Jan 17, 2021
@nsosnsos
Merge pull request open-mpi#7 from RainybIue/huawei
386000f 
increase the check of data size
@janciesko janciesko mentioned this issue Feb 25, 2021
Open
@wzamazon wzamazon mentioned this issue Sep 7, 2021
Closed
@frizwi frizwi mentioned this issue Sep 20, 2021
Open
Open
@bgoglin bgoglin mentioned this issue Feb 8, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ompiteam ompiteam

Labels
bug Severity: minor
Projects
None yet
Milestone
Future
Development

No branches or pull requests
3 participants
@jsquyres @hjelmn @ompiteam