FWIW: source inspection of libtool.m4 reveals that the same problem
probably exists with g95 on OpenBSD (same flawed probe logic is used),
though I have no g95 on my OpenBSD systems to confirm or refute this.
G95/f95 should be fine on other systems because {Net,Open}BSD are the only
platforms on which libtool must resort to silly tricks to determine if the
compiler's object format is a.out or elf.
-Paul
On Mon, Jan 13, 2014 at 11:44 PM, Paul Hargrove <phhargr...@lbl.gov> wrote:
> The new release note reads:
>
> - Building Open MPI on a NetBSD-6 AMD64 system will run into obscure
> compile-time failures if f95/g95 is found in the path. You can work
> around such problems by removing g95 from your path.
>
> The problem surfaces on i386 too, and use of gfortran seems the best fix.
> My recommended rewrite:
>
> - On NetBSD-6 (at least AMD64 and i386) libtool misidentifies properties of
> f95/g95, leading to obscure compile-time failures if used to build Open
> MPI.
> You can work around this issue by either installing gfortran, removing
> f95
> and g95 from your path, or by configuring Open MPI to disable the fortran
> bindings.
>
> -Paul
>
>
>
> On Mon, Jan 13, 2014 at 9:01 AM, Jeff Squyres (jsquyres) <
> jsquy...@cisco.com> wrote:
>
>> Sounds like a release note to me. Thanks for tracking this down!
>>
>> On Jan 11, 2014, at 5:56 PM, Paul Hargrove <phhargr...@lbl.gov> wrote:
>>
>> > I have been able to make some progress on understanding the cause of
>> this issue.
>> >
>> > Looking at the generated libtool is is clearly broken, being for an
>> a.out system when this is an elf platform.
>> > Comparison to the WORKING netbsd6-i386 platform revealed the difference
>> is the presence of g95 on the amd64 box.
>> >
>> > Examining the configure output reveals that libtools' probes of f95
>> decide (incorrectly) that this is an a.out platform:
>> >
>> > checking whether the f95 linker (/usr/bin/ld) supports shared
>> libraries... Warning (116): Reading file <stdin> as free form
>> > yes
>> > checking dynamic linker characteristics... Warning (116): Reading file
>> <stdin> as free form
>> > NetBSD (a.out) ld.so
>> >
>> > Even though probes of gcc and g++ find elf:
>> >
>> > checking whether the gcc -std=gnu99 linker (/usr/bin/ld) supports
>> shared libraries... yes
>> > checking whether -lc should be explicitly linked in... no
>> > checking dynamic linker characteristics... NetBSD ld.elf_so
>> >
>> > checking whether the g++ linker (/usr/bin/ld) supports shared
>> libraries... yes
>> > checking dynamic linker characteristics... NetBSD ld.elf_so
>> >
>> >
>> > I have confirmed that installing g95 on the netbsd6-i386 platform
>> (indirect consequence of "pkgin upgrade") causes the failure to manifest
>> there too.
>> > Similarly, removing g95 on the netbsd6-amd64 system resolves the
>> original problem.
>> >
>> > I am not personally interested in pursing the root cause of the
>> libtool+g95 problem.
>> > However, I have attached configure's stdout and the config.log (for
>> 1.9a1r30255) for anybody who is.
>> >
>> >
>> > -Paul
>> >
>> >
>> > On Thu, Dec 19, 2013 at 7:06 PM, Paul Hargrove <phhargr...@lbl.gov>
>> wrote:
>> > Attached is the output from "make install" of 1.7.4rc1 + Jeff's fix for
>> the symbol conflict on "if_mtu".
>> >
>> > There appear to be at least 2 issues.
>> >
>> > 1) There are lots of (not fatal) messages about ldconfig not existing,
>> but according to he NetBSD lists that utility went away with the conversion
>> from a.out to ELF.
>> >
>> > 2) Many warnings of the form
>> > *** Warning: linker path does not have real file for library
>> >
>> > 3) The final (fatal) error about .libs/mca_btl_sm.soT not existing.
>> >
>> > I am going to see if I can get a better result using the system libtool
>> (which is 2.2.6b, thus OLDER than OMPI's 2.4.2) and will report back with
>> my results.
>> >
>> > -Paul
>> >
>> > --
>> > Paul H. Hargrove phhargr...@lbl.gov
>> > Future Technologies Group
>> > Computer and Data Sciences Department Tel: +1-510-495-2352
>> > Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
>> >
>> >
>> >
>> > --
>> > Paul H. Hargrove phhargr...@lbl.gov
>> > Future Technologies Group
>> > Computer and Data Sciences Department Tel: +1-510-495-2352
>> > Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
>> >
>> <config.log.bz2><configure.stdout.bz2>_______________________________________________
>> > devel mailing list
>> > de...@open-mpi.org
>> > http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>
>>
>> --
>> Jeff Squyres
>> jsquy...@cisco.com
>> For corporate legal information go to:
>> http://www.cisco.com/web/about/doing_business/legal/cri/
>>
>> _______________________________________________
>> devel mailing list
>> de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>
>
>
>
> --
> Paul H. Hargrove phhargr...@lbl.gov
> Future Technologies Group
> Computer and Data Sciences Department Tel: +1-510-495-2352
> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
>
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
Computer and Data Sciences Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
