NetBSD Problem Report #35307

From dan@mcmahill.net  Thu Dec 21 17:05:04 2006
Return-Path: <dan@mcmahill.net>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id 3E3B963BA73
	for <gnats-bugs@gnats.NetBSD.org>; Thu, 21 Dec 2006 17:05:04 +0000 (UTC)
Message-Id: <200612211705.kBLH52x0025060@bondage.mcmahill.net>
Date: Thu, 21 Dec 2006 12:05:02 -0500 (EST)
From: dmcmahill@NetBSD.org
Reply-To: dmcmahill@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: libtool vs compiler.mk
X-Send-Pr-Version: 3.95

>Number:         35307
>Category:       pkg
>Synopsis:       libtool vs compiler.mk
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Dec 21 17:10:01 +0000 2006
>Closed-Date:    
>Last-Modified:  Fri Oct 15 04:55:28 +0000 2010
>Originator:     Dan McMahill
>Release:        pkgsrc as of 2006-12-21
>Organization:
NetBSD
>Environment:


>Description:

compiler.mk uses the list of compilers in PKGSRC_COMPILER along with various
variables like NOT_FOR_COMPILER to decide which compiler to use for a particular
package.

One problem here is that libtool-base is compiled with a particular compiler
and becomes customized to that compiler.  Consider the following example now:

You want to generally use sunpro for the compiler since the binaries tend
to run faster on sparcs and also that seems to be the way to getting a working
firefox.  Libtool is built around sunpro.

Now you want to build something else that is simply not compatible with sunpro
because it relies too much on g++ or for whatever reason is not easy to 
fix for sunpro.  Ok, put NOT_FOR_COMPILER+= sunpro in that packages Makefile
and in /etc/mk.conf make sure you have PKGSRC_COMPILER= sunpro gcc

The magic in the compiler and wrapper framework now tries to use gcc for this
particular package but unfortunately if the particular package has USE_LIBTOOL,
you get a libtool which is not compatible with the gcc toolchain.


>How-To-Repeat:

>Fix:

I'm thinking that perhaps when PKGSRC_COMPILER is set to multiple choices that 
there needs to be a /usr/pkg/bin/libtool-gcc as well as a /usr/pkg/bin/libtool-sunpro.
Then bsd.wrapper.mk would pick out the correct libtool for the currently 
selected toolchain.

Now the question is the best way to implement that.  Perhaps devel/libtool-base-sunpro,
devel/libtool-base-gcc, etc should be created and they would all point to the same files
but just set ONLY_FOR_COMPILER to get the right one.



>Release-Note:

>Audit-Trail:

State-Changed-From-To: open->feedback
State-Changed-By: asau@NetBSD.org
State-Changed-When: Fri, 19 Feb 2010 11:19:51 +0000
State-Changed-Why:
Libtool area changed a lot, does the problem persist?


From: Dan McMahill <dmcmahill@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc: pkg-manager@netbsd.org, pkgsrc-bugs@netbsd.org, 
 gnats-admin@netbsd.org, asau@NetBSD.org
Subject: Re: pkg/35307 (libtool vs compiler.mk)
Date: Sat, 20 Feb 2010 00:45:04 -0500

 asau@NetBSD.org wrote:
 > Synopsis: libtool vs compiler.mk
 > 
 > State-Changed-From-To: open->feedback
 > State-Changed-By: asau@NetBSD.org
 > State-Changed-When: Fri, 19 Feb 2010 11:19:51 +0000
 > State-Changed-Why:
 > Libtool area changed a lot, does the problem persist?
 > 
 > 

 as near as I can tell the same problem exists.  The basic issue is this:

 libtool creates tags which are stored in ${prefix}/bin/libtool and they 
 are based on the compiler characteristics in the compiler used to build 
 libtool.  This means if you ever try to switch from say f2c-f77 for your 
 fortran compiler to gfortran, you'll have a bad libtool and you end up 
 having to rebuild everything.

From: Joerg Sonnenberger <joerg@britannica.bec.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/35307 (libtool vs compiler.mk)
Date: Sat, 20 Feb 2010 06:53:07 +0100

 On Sat, Feb 20, 2010 at 05:50:03AM +0000, Dan McMahill wrote:
 >  libtool creates tags which are stored in ${prefix}/bin/libtool and they 
 >  are based on the compiler characteristics in the compiler used to build 
 >  libtool.  This means if you ever try to switch from say f2c-f77 for your 
 >  fortran compiler to gfortran, you'll have a bad libtool and you end up 
 >  having to rebuild everything.

 Everything is a bit too much. Rebuildling libtool-base and the fortran
 dependencies should certainly be enough.

 Joerg

From: Dan McMahill <dmcmahill@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc: pkg-manager@netbsd.org, gnats-admin@netbsd.org, 
 pkgsrc-bugs@netbsd.org
Subject: Re: pkg/35307 (libtool vs compiler.mk)
Date: Sat, 20 Feb 2010 01:39:26 -0500

 Joerg Sonnenberger wrote:
 > The following reply was made to PR pkg/35307; it has been noted by GNATS.
 > 
 > From: Joerg Sonnenberger <joerg@britannica.bec.de>
 > To: gnats-bugs@NetBSD.org
 > Cc: 
 > Subject: Re: pkg/35307 (libtool vs compiler.mk)
 > Date: Sat, 20 Feb 2010 06:53:07 +0100
 > 
 >  On Sat, Feb 20, 2010 at 05:50:03AM +0000, Dan McMahill wrote:
 >  >  libtool creates tags which are stored in ${prefix}/bin/libtool and they 
 >  >  are based on the compiler characteristics in the compiler used to build 
 >  >  libtool.  This means if you ever try to switch from say f2c-f77 for your 
 >  >  fortran compiler to gfortran, you'll have a bad libtool and you end up 
 >  >  having to rebuild everything.
 >  
 >  Everything is a bit too much. Rebuildling libtool-base and the fortran
 >  dependencies should certainly be enough.

 everything is maybe a bit much, but most of the things written in 
 fortran are lower level libs.  So you end up rebuilding low level 
 packages and then the ones which depended upon those as well.

State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Fri, 15 Oct 2010 04:55:28 +0000
State-Changed-Why:
feedback was received a while back.
ISTM that building a separate libtool script for each compiler in use is the
right approach.


>Unformatted:

Home	PR Database Search