NetBSD Problem Report #51311

From www@NetBSD.org  Mon Jul  4 22:27:21 2016
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 8B0BB7A47B
	for <gnats-bugs@gnats.NetBSD.org>; Mon,  4 Jul 2016 22:27:21 +0000 (UTC)
Message-Id: <20160704222720.81A287AAB5@mollari.NetBSD.org>
Date: Mon,  4 Jul 2016 22:27:20 +0000 (UTC)
From: fdupont@isc.org
Reply-To: fdupont@isc.org
To: gnats-bugs@NetBSD.org
Subject: libtool fails to build shared libraries
X-Send-Pr-Version: www-1.0

>Number:         51311
>Category:       pkg
>Synopsis:       libtool fails to build shared libraries
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    joerg
>State:          open
>Class:          support
>Submitter-Id:   net
>Arrival-Date:   Mon Jul 04 22:30:00 +0000 2016
>Last-Modified:  Thu Jul 07 17:20:00 +0000 2016
>Originator:     Francis Dupont
>Release:        7.0.1
>Organization:
Internet Systems Consortium
>Environment:
7.0.1 amd64 aka x86_64
>Description:
On a fresh NetBSD 7.0.1 amd64/x86_64 VM with last auomake, autoconf and libtool packages installed from http://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/x86_64/7.0.1/All when I try to build a shared library libtool returns:
*** Warning: linker path does not have real file for library -lgcc
and finally fails to build the shared library. Note it works fine on 6.1.5.

I investigated to find the reasons of the problem:
 - on 6.1.5 the compiler (g++) uses for system libraries "-lgcc -lc -lgcc", on 7.0.1 it uses a more complex sequence with -lgcc, -lgcc_s and --as-needed. Just tries "g++ -v" on some c++ input.

 - on 7.0.1 the gcc libraries are libgcc.a and libgcc_s.so, there is no libgcc_s.a nor libgcc.so.

 - autoconf produces configure files with for$host_os matching netbsd*:
    # Workaround some broken pre-1.5 toolchains
    output_verbose_link_cmd='$CC -shared $CFLAGS -v conftest.$objext 2>&1 | grep conftest.$objext | $SED -e "s:-lgcc -lc -lgcc::"'

 - so when configure sets the config variables at the end of libtool I get in postdeps the system libraries (-lgcc and -lgcc_s). As there is no libgcc.so available libtool raises the warning, etc. 6.1.5 works because of the sed in configure...

I tried with success two solutions:
 - remove the extra system libraries from postdeps in libtool or postdeps_CXX in config.status

 - allows libtool to link a .a into a shared library: set to yes allow_libtool_libs_with_static_runtimes in libtool or enable_shared_with_static_runtimes_CXX in config.status

You can find more details at http://kea.isc.org/wiki/SystemNotesNetBSD
(as a Kea developer and a NetBSD user for more than 20 years I wanted to help people to build Kea on NetBSD, unfortunately with mixed results...)
>How-To-Repeat:
$ echo 'int main() { return 0; }' > sample.cc
$ g++ -v -o sample sample.cc

This shows the system library setup used by g++ in the last/ld line.

After if you'd like to do the same than me:
install automake, libtool, pkg-config, log4cplus, boost and git packages.
Get kea sources, configure and launch make:
$ git clone https://github.com/isc-projects/kea.git
$ cd kea
$ autoreconf -i
$ ./configure
$ make

You should get very quickly the full warning for libtool and it stops some time later.

I recommend you build a smaller (in particular for dependencies) example.
>Fix:
Contact the autoconf and/or libtool core team to find the best way to cleanup this mess. And if possible this time avoid something like the "Workaround some broken pre-1.5 toolchains"...

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: pkg-manager->joerg
Responsible-Changed-By: wiz@NetBSD.org
Responsible-Changed-When: Tue, 05 Jul 2016 06:18:00 +0000
Responsible-Changed-Why:
Over to MAINTAINER

Joerg, that's the same problem I told you about this weekend.


From: Joerg Sonnenberger <joerg@bec.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/51311 (libtool fails to build shared libraries)
Date: Tue, 5 Jul 2016 10:33:06 +0200

 So the short version here is: Works As Intended. We do go to some length
 to make sure that libtool.m4 is the prestine upstream version, so that
 if you build a package for redistribution, it is not polluted with any
 local package and you get the same result as on other systems. As a side
 effect, this means that the fixes for various platforms in pkgsrc are
 also not included. While I do regular runs to upstream them, it is
 always a game of cat and mouse. It doesn't help that new libtool
 versions tend to add needs for new patches...

 Joerg

From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/51311 (libtool fails to build shared libraries)
Date: Thu, 7 Jul 2016 17:15:59 +0000

 On Tue, Jul 05, 2016 at 08:35:01AM +0000, Joerg Sonnenberger wrote:
  > From: Joerg Sonnenberger <joerg@bec.de>
  > To: gnats-bugs@NetBSD.org
  > Cc: 
  > Subject: Re: pkg/51311 (libtool fails to build shared libraries)
  > Date: Tue, 5 Jul 2016 10:33:06 +0200
  > 
  >  So the short version here is: Works As Intended. We do go to some length
  >  to make sure that libtool.m4 is the prestine upstream version, so that
  >  if you build a package for redistribution, it is not polluted with any
  >  local package and you get the same result as on other systems. As a side
  >  effect, this means that the fixes for various platforms in pkgsrc are
  >  also not included. While I do regular runs to upstream them, it is
  >  always a game of cat and mouse. It doesn't help that new libtool
  >  versions tend to add needs for new patches...

 This state is also, however, not helpful for people who install the
 thing to use it directly and want it to work.

 -- 
 David A. Holland
 dholland@netbsd.org

>Unformatted:

Home	PR Database Search