Re: [OMPI devel] Why no release tags in open-mpi/ompi repository?

[Jed Brown]

"Dave Goodell (dgoodell)"  writes:
> You're not wrong about the advantages of a merge-based workflow.  I
> just don't think it changes what the community is choosing to do right
> now.

No worries.  I didn't notice previous workflow discussion and I've seen
history repeat itself with minor variations many times over the years,
so I thought it was worth commenting.

>>> Put differently: the dev tag is solely for ordering of nightly snapshot 
>>> tarballs.
>> 
>> It affects git describe output as a side-effect and when someone writes
>> the mailing list with a bug in a year-old nightly snapshot, you'll need
>> to query the repository (or have a better memory than me) to have any
>> idea what they're working with.  Perhaps you are blessed with users that
>> don't do things like this.
>
> Checking the repo isn't particularly onerous, IMO.  It's a lot easier
> than searching old bug tickets, which you're also likely to need to do
> when dealing with bugs reported against old snapshots.  Also, there's
> almost no scenario where a user should be reporting bugs against a
> years-old "master" snapshot.  

I'm glad you have such delightful users. ;-)


pgp9pTgoBHEBB.pgp
Description: PGP signature

Re: [OMPI devel] Why no release tags in open-mpi/ompi repository?

[Dave Goodell (dgoodell)]

On Oct 17, 2014, at 9:51 AM, Jed Brown  wrote:

> "Jeff Squyres (jsquyres)"  writes:
> 
>> Meaning: we deliberately chose not to change the development style of
>> the community to "develop on release branch" when we moved to git.
> 
> Understood.  It's your choice, but workflow is a big feature of Git.

Jed, I initially advocated for a merge-based workflow when we were planning the 
transition to Git, but others in the community felt that it would be too 
painful to simultaneously learn a new VCS and invert the flow of development.  
I'm still not 100% sure that sticking to the cherry-pick workflow was really 
the right call, but I've made peace with it for now.

We can certainly live with this workflow for a while and change again later if 
desired.  Separating the shocks to non-git-comfortable developers is a good 
thing, IMO.

>> If github would implement per-branch push ACLs, then we'd squash down
>> to a single repo, and all this would be easier.
>> 
>> But given the relative inexperience with git in our community (which
>> is noticeable via some mistakes on the ompi repo already!) and our
>> history of only allowing regulated commits to release branches, we
>> chose the (admittedly somewhat awkward) 2-repo model.
> 
> You could push release tags to open-mpi/ompi without pushing the branches.

I'm not sure this is less confusing.  It gives the illusion that "ompi" 
contains all of the release development as well, but in reality you need 
"ompi-release" to get anything beyond the latest tagged release.

>>> and it deprives you of context when you
>>> have no idea whether "dev-BIGNUMBER" is earlier or later than a given
>>> release.  (Does it have those features/bugs or not?)
>> 
>> Even if OMPI was just in one git repo, the number of commits on master
>> since dev is unrelated to a given release.
> 
> If integration branches were merged upward, "git describe" would yield
> names like v1.8.3-84-g51a7c90, which tells you immediately that it's 84
> commits "ahead" of v1.8.3.

You're not wrong about the advantages of a merge-based workflow.  I just don't 
think it changes what the community is choosing to do right now.

>> Put differently: the dev tag is solely for ordering of nightly snapshot 
>> tarballs.
> 
> It affects git describe output as a side-effect and when someone writes
> the mailing list with a bug in a year-old nightly snapshot, you'll need
> to query the repository (or have a better memory than me) to have any
> idea what they're working with.  Perhaps you are blessed with users that
> don't do things like this.

Checking the repo isn't particularly onerous, IMO.  It's a lot easier than 
searching old bug tickets, which you're also likely to need to do when dealing 
with bugs reported against old snapshots.  Also, there's almost no scenario 
where a user should be reporting bugs against a years-old "master" snapshot.  
Snapshots from the release branches have more useful names (e.g., 
v1.8.3-39-gd07d53e).

-Dave

Re: [OMPI devel] Open MPI 1.8: link problem when Fortran+C+Platform LSF

[Paul Hargrove]

Markus,

I based my suggestion on the presence of certain keywords in the error
message, not on any mental model of the compiler or linker action on your
input.  I don't think there is any valid reason one should *expect* a need
to compile or link with "mpif90 -fPIC".  So, I am afraid I cannot answer as
to why this fixes the problem.

-Paul

On Sun, Oct 19, 2014 at 10:44 PM, Frings, Markus  wrote:

>  Compiling the sources with -fPIC fixes the issue. But I wonder why I have
> to add -fPIC when I want to compile with mpif90, but not when I use ifort
> directly. With mpif90 I also use ifort with some additional flags and
> libraries as mpif90 --show-me shows.
>
>
> Markus Frings, M.Sc.
>
>  Chair for Computational Analysis of Technical Systems (CATS)
> RWTH Aachen University
> Schinkelstrasse 2, Room 222a
> D-52062 Aachen
>
>  Phone +49 (0)241 80 99932
> fri...@cats.rwth-aachen.de
> http://www.cats.rwth-aachen.de
>
>  On 18.10.2014, at 02:24, Paul Hargrove  wrote:
>
>  I know of two possibilities:
>
>  1) I cannot be certain but since the message concerns a PC-relative
> addressing mode, it is possible that something needs to be compiled with
> -fPIC to fix the issue.  See if adding that option to any of the mpicc
> commands helps.
>
> 2) Try adding ONE of "-ll", "-lfl" or "-lfl_pic" to include the lex/flex
> support lib.   This is PROBABLY the wrong solution because that lib defines
> its own "main()".
>
>  -Paul
>
>
>
> On Fri, Oct 17, 2014 at 4:56 PM, Jeff Squyres (jsquyres) <
> jsquy...@cisco.com> wrote:
>
>> I think the LSF part of this may be a red herring.  Do you really need to
>> add "-lbat -llsf" to the command line to make it work?
>>
>> The error message *sounds* like y.tab.o was compiled differently than
>> others...?  It's hard to know without seeing the output of mpicc --showme.
>>
>>
>> On Oct 17, 2014, at 7:51 AM, Ralph Castain  wrote:
>>
>> > Forwarding this for Paul until his email address gets updated on the
>> User list:
>> >
>> >> Begin forwarded message:
>> >>
>> >> Date: October 17, 2014 at 6:35:31 AM PDT
>> >> From: Paul Kapinos 
>> >> To: Open MPI Users 
>> >> Cc: "Kapinos, Paul" , <
>> fri...@cats.rwth-aachen.de>
>> >> Subject: Open MPI 1.8: link problem when Fortran+C+Platform LSF
>> >>
>> >> Dear Open MPI developer,
>> >>
>> >> we have both Open MPI 1.6(.5) and 1.8(.3) in our cluster, configured
>> to be used with Platform LSF.
>> >>
>> >> One of our users run into an issue when trying to link his code
>> (combination of lex/C and Fortran) with v.1.8, whereby with OpenMPI/1.6er
>> the code can be linked OK.
>> >>
>> >>> $ make
>> >>> mpif90 -c main.f90
>> >>> yacc -d example4.y
>> >>> mpicc -c y.tab.c
>> >>> mpicc -c mymain.c
>> >>> lex example4.l
>> >>> mpicc -c lex.yy.c
>> >>> mpif90 -o example main.o y.tab.o mymain.o lex.yy.o
>> >>> ld: y.tab.o(.text+0xd9): unresolvable R_X86_64_PC32 relocation
>> against symbol `yylval'
>> >>> ld: y.tab.o(.text+0x16f): unresolvable R_X86_64_PC32 relocation
>> against symbol `yyval'
>> >>> ...
>> >>
>> >> looking into "mpif90 --show-me" let us see that the link line and
>> possibly the philosophy behind it has been changed, there is also a note on
>> it:
>> >>
>> >> # Note that per https://svn.open-mpi.org/trac/ompi/ticket/3422, we
>> >> # intentionally only link in the MPI libraries (ORTE, OPAL, etc. are
>> >> # pulled in implicitly) because we intend MPI applications to only use
>> >> # the MPI API.
>> >>
>> >>
>> >>
>> >>
>> >> Well, by now we know two workarounds:
>> >> a) add "-lbat -llsf" to the link line
>> >> b) add " -Wl,--as-needed" to the link line
>> >>
>> >> What would be better? Maybe one of this should be added to
>> linker_flags=..." in the .../share/openmpi/mpif90-wrapper-data.txt file? As
>> of the note above, (b) would be better?
>> >>
>> >> Best
>> >>
>> >> Paul Kapinos
>> >>
>> >> P.S. $ mpif90 --show-me
>> >>
>> >> 1.6.5
>> >> ifort -nofor-main -I/opt/MPI/openmpi-1.6.5/linux/intel/include
>> -fexceptions -I/opt/MPI/openmpi-1.6.5/linux/intel/lib
>> -L/opt/lsf/9.1/linux2.6-glibc2.3-x86_64/lib
>> -L/opt/MPI/openmpi-1.6.5/linux/intel/lib -lmpi_f90 -lmpi_f77 -lmpi
>> -losmcomp -lrdmacm -libverbs -lrt -lnsl -lutil -lpsm_infinipath -lbat -llsf
>> -ldl -lm -lnuma -lrt -lnsl -lutil
>> >>
>> >> 1.8.3
>> >> ifort -I/opt/MPI/openmpi-1.8.3/linux/intel/include
>> -fexceptions -I/opt/MPI/openmpi-1.8.3/linux/intel/lib
>> -L/opt/lsf/9.1/linux2.6-glibc2.3-x86_64/lib -Wl,-rpath
>> -Wl,/opt/lsf/9.1/linux2.6-glibc2.3-x86_64/lib -Wl,-rpath
>> -Wl,/opt/MPI/openmpi-1.8.3/linux/intel/lib -Wl,--enable-new-dtags
>> -L/opt/MPI/openmpi-1.8.3/linux/intel/lib -lmpi_usempif08
>> -lmpi_usempi_ignore_tkr -lmpi_mpifh -lmpi
>> >>
>> >> P.S.2 $ man ld
>> >> 
>> >>   --as-needed
>> >>   --no-as-needed
>> >>   This option affects ELF DT_NEEDED