GNU bug report logs - #9795
Disabling fortran (what's it for?)

Previous Next

To reply to this bug, email your comments to 9795 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ryan Schmidt <libtool-2011d <at> ryandesign.com>
To: bug-libtool <at> gnu.org
Subject: Disabling fortran (what's it for?)
Date: Wed, 19 Oct 2011 01:24:41 -0500

Hello, I'm writing on behalf of the MacPorts project. In MacPorts, many users (some of the tickets are listed below) have experienced a problem building libtool, where the shared library libltdl.dylib doesn't get built. It took awhile to identify that this was the problem, because the failure was silent; the libtool port seemed to install successfully, but did not contain libltdl.dylib, which caused various problems for other software down the road. Once we added a check to the libtool port to prevent the installation from completing if libltdl.dylib didn't get built, we were able to work out that the common thread was the presence of a fortran compiler. Some users had a fortran compiler installed at /usr/bin/gfortran; others had /usr/bin/g77 or /bin/f77. While we find it an error for any 3rd-party package to have installed files in those locations, since those are system directories, we nevertheless have the situation that these packages do exist, so we have to deal with them.

I'm also able to reproduce the problem by just creating a script called "gfortran" somewhere in the path that does nothing more than exit 1.

So the questions are:

* How do we prevent libtool from attempting to use gfortran, g77, f77, or any other fortran compiler, even if it's installed?

* For what reason is libtool looking for a fortran compiler at all? What does it use it for?

Thanks.


https://trac.macports.org/ticket/23684
https://trac.macports.org/ticket/25417
https://trac.macports.org/ticket/26908
https://trac.macports.org/ticket/30018
https://trac.macports.org/ticket/30037
https://trac.macports.org/ticket/30043
https://trac.macports.org/ticket/30105
https://trac.macports.org/ticket/30395

Message #8 received at 9795 <at> debbugs.gnu.org (full text, mbox):

From: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
To: Ryan Schmidt <libtool-2011d <at> ryandesign.com>
Cc: 9795 <at> debbugs.gnu.org, bug-libtool <at> gnu.org
Subject: Re: bug#9795: Disabling fortran (what's it for?)
Date: Wed, 19 Oct 2011 09:03:27 -0500 (CDT)

On Wed, 19 Oct 2011, Ryan Schmidt wrote:
>
> * For what reason is libtool looking for a fortran compiler at all? What does it use it for?

Libtool supports building and linking Fortran code so it tests the 
Fortran compiler.  The libltdl library should *not* be dependent on 
Fortran in any way.

Bob
-- 
Bob Friesenhahn
bfriesen <at> simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Message #14 received at 9795 <at> debbugs.gnu.org (full text, mbox):

From: "Ralf Wildenhues" <Ralf.Wildenhues <at> gmx.de>
To: Ryan Schmidt <libtool-2011d <at> ryandesign.com>
Cc: 9795 <at> debbugs.gnu.org
Subject: Re: bug#9795: Disabling fortran (what's it for?)
Date: Wed, 19 Oct 2011 21:17:05 +0200

Hello Ryan,

* Ryan Schmidt wrote on Wed, Oct 19, 2011 at 08:24:41AM CEST:
> Hello, I'm writing on behalf of the MacPorts project. In MacPorts, many users (some of the tickets are listed below) have experienced a problem building libtool, where the shared library libltdl.dylib doesn't get built. It took awhile to identify that this was the problem, because the failure was silent; the libtool port seemed to install successfully, but did not contain libltdl.dylib, which caused various problems for other software down the road. Once we added a check to the libtool port to prevent the installation from completing if libltdl.dylib didn't get built, we were able to work out that the common thread was the presence of a fortran compiler. Some users had a fortran compiler installed at /usr/bin/gfortran; others had /usr/bin/g77 or /bin/f77. While we find it an error for any 3rd-party package to have installed files in those locations, since those are system directories, we nevertheless have the situation that these packages do exist, so we have to deal with them.

This is libtool < 2.0, right?

Please update.  We've fixed this years ago.

Thanks,
Ralf

Message #17 received at 9795 <at> debbugs.gnu.org (full text, mbox):

From: Ryan Schmidt <libtool-2011d <at> ryandesign.com>
To: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
Cc: 9795 <at> debbugs.gnu.org
Subject: Re: bug#9795: Disabling fortran (what's it for?)
Date: Wed, 19 Oct 2011 17:21:59 -0500

On Oct 19, 2011, at 14:17, Ralf Wildenhues wrote:

> This is libtool < 2.0, right?
> 
> Please update.  We've fixed this years ago.


Oh no, this is with current versions. The ticket URLs I provided show the problem with libtool 2.2.6b:

https://trac.macports.org/ticket/23684

And 2.4:

https://trac.macports.org/ticket/30105

And I experienced the problem when trying to update to 2.4.2, which is what prompted me to file this report and try to resolve the issue once and for all.

Message #20 received at 9795 <at> debbugs.gnu.org (full text, mbox):

From: Peter O'Gorman <peter <at> pogma.com>
To: Ryan Schmidt <libtool-2011d <at> ryandesign.com>
Cc: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>, 9795 <at> debbugs.gnu.org
Subject: Re: bug#9795: Disabling fortran (what's it for?)
Date: Thu, 20 Oct 2011 19:47:08 -0500

On 10/19/2011 05:21 PM, Ryan Schmidt wrote:
>
> On Oct 19, 2011, at 14:17, Ralf Wildenhues wrote:
>
>> This is libtool<  2.0, right?
>>
>> Please update.  We've fixed this years ago.
>
>
> Oh no, this is with current versions. The ticket URLs I provided show the problem with libtool 2.2.6b:
>
> https://trac.macports.org/ticket/23684
>
> And 2.4:
>
> https://trac.macports.org/ticket/30105

I think that because the installed fortran compiler is somehow broken 
libtool detects that the compiler can not create shared libraries. 
Fortran being tested last must overwrite the varaibles that were set for 
the C and C++ compiler - so libtool does not create any shared libraries 
at all. I'll look into it.

Thanks,
Peter

Message #23 received at 9795 <at> debbugs.gnu.org (full text, mbox):

From: Peter O'Gorman <peter <at> pogma.com>
To: Ryan Schmidt <libtool-2011d <at> ryandesign.com>
Cc: 9795 <at> debbugs.gnu.org
Subject: Re: bug#9795: Disabling fortran (what's it for?)
Date: Fri, 21 Oct 2011 11:35:09 -0500

On 10/20/2011 07:47 PM, Peter O'Gorman wrote:

>
> I think that because the installed fortran compiler is somehow broken
> libtool detects that the compiler can not create shared libraries.
> Fortran being tested last must overwrite the varaibles that were set for
> the C and C++ compiler - so libtool does not create any shared libraries
> at all. I'll look into it.

The "can_build_shared" shell variable is not tagged (not one var per 
compiler), so even though the C and C++ compilers would work, any broken 
compiler that comes later in the tests will cause libtool to not build 
shared libraries.

The code in question is a bit of a mess and may take a little sorting out.

In the meantime, if you build libtool with

configure F77=no FC=no; make

then it should disable the fortran tag. The installed libtool script 
then will not be able to build fortran code, but the use of the 
installed build script to build packages is not encouraged anyway.

Your users with broken fortran compilers will continue to see brokenness 
building other packages, since most autotools based build systems embed 
some version of libtool.

Peter

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.