NetBSD Problem Report #46329

From www@NetBSD.org  Fri Apr 13 07:31:44 2012
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	by www.NetBSD.org (Postfix) with ESMTP id 9E42F63BEE1
	for <gnats-bugs@gnats.NetBSD.org>; Fri, 13 Apr 2012 07:31:44 +0000 (UTC)
Message-Id: <20120413073143.BD1BB63BBEC@www.NetBSD.org>
Date: Fri, 13 Apr 2012 07:31:43 +0000 (UTC)
From: joern.clausen@uni-bielefeld.de
Reply-To: joernc@gmail.com
To: gnats-bugs@NetBSD.org
Subject: graphics/ImageMagick: visibility on Solaris with GCC4 still broken if using native ld
X-Send-Pr-Version: www-1.0

>Number:         46329
>Category:       pkg
>Synopsis:       graphics/ImageMagick: visibility on Solaris with GCC4 still broken if using native ld
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    solaris-pkg-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Apr 13 07:35:00 +0000 2012
>Last-Modified:  Tue Jan 29 06:46:47 +0000 2019
>Originator:     Jörn Clausen
>Release:        
>Organization:
University of Bielefeld
>Environment:
>Description:
The assumption that the visibility attribute can be used when using GCC 4 is wrong. It still does not work on Solaris (only i86, maybe) when using the native linker. This breaks graphics/ImageMagick and some other packages, that base their decision to use visibility solely on the type and version of the compiler:

  CCLD   magick/libMagickCore.la
Text relocation remains                         referenced
    against symbol                  offset      in file
ResetQuantumState                   0x818       magick/.libs/magick_libMagickCore_la-quantum.o
ResetQuantumState                   0xf75b      magick/.libs/magick_libMagickCore_la-quantum-export.o
ResetQuantumState                   0xc8a1      magick/.libs/magick_libMagickCore_la-quantum-import.o
SyncImagePixelCache                 0x4435      magick/.libs/magick_libMagickCore_la-colorspace.o
SyncImagePixelCache                 0x3645      magick/.libs/magick_libMagickCore_la-image.o
SyncImagePixelCache                 0x3c42      magick/.libs/magick_libMagickCore_la-image.o
SyncImagePixelCache                 0x4c58      magick/.libs/magick_libMagickCore_la-image.o
ld: fatal: relocations remain against allocatable but non-writable sections

This error was generated by using a stand-alone GCC 4.7.0 that uses native assembler and linker.
>How-To-Repeat:

>Fix:
--- magick/method-attribute.h.orig      2012-02-19 18:15:53.000000000 +0000
+++ magick/method-attribute.h
@@ -92,7 +92,7 @@ extern "C" {
 #  pragma warning(disable : 4996)
 # endif
 #else
-# if __GNUC__ >= 4
+# if __GNUC__ >= 4 && !defined(__sun__)
 #  define MagickExport __attribute__ ((visibility ("default")))
 #  define MagickPrivate  __attribute__ ((visibility ("hidden")))
 # else

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: pkg-manager->solaris-pkg-people
Responsible-Changed-By: hauke@NetBSD.org
Responsible-Changed-When: Fri, 13 Apr 2012 07:48:26 +0000
Responsible-Changed-Why:
A Solaris issue.


From: Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/46329 (graphics/ImageMagick: visibility on Solaris with GCC4 still broken if using native ld)
Date: Fri, 13 Apr 2012 11:44:08 +0200

 graphics/ImageMagick built without problems in my SunOS 5.11 bulk build
 using lang/gcc46. Could it be that your gcc 4.7 is not configured
 correctly? I can't believe that a newer gcc4 suddenly lost support for
 the visibility attribute.

 Gcc 4.x needs some variant of objdump to be able to detect whether the
 visibility attribute can be supported. This is why lang/gcc44 and
 lang/gcc46 set this on SunOS:
 CONFIGURE_ENV+=		OBJDUMP=/usr/sfw/bin/gobjdump

 (Admittedly, this may not work on SunOS variants that don't have sfw or
 don't have objdump installed.)

From: =?ISO-8859-1?Q?J=F6rn_Clausen?= <joern.clausen@uni-bielefeld.de>
To: gnats-bugs@NetBSD.org
Cc: Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org>,
 solaris-pkg-people@NetBSD.org, gnats-admin@NetBSD.org, pkgsrc-bugs@NetBSD.org
Subject: Re: pkg/46329 (graphics/ImageMagick: visibility on Solaris with GCC4
 still broken if using native ld)
Date: Fri, 13 Apr 2012 11:52:38 +0200

 On 13.04.12 11:45, Hans Rosenfeld wrote:
 >   graphics/ImageMagick built without problems in my SunOS 5.11 bulk build
 >   using lang/gcc46. Could it be that your gcc 4.7 is not configured
 >   correctly? I can't believe that a newer gcc4 suddenly lost support for
 >   the visibility attribute.

 It's the linker that does not support the code generated by GCC. As 
 mentioned, I use /usr/ccs/bin/ld, not binutils.

 I admit the patch "fixes" cases that are not broken, but as long as 
 autoconf provides no method for determining the linker in use, this is 
 the only workaround.

 -- 
   Jörn Clausen                             joern.clausen@uni-bielefeld.de
   Hochschulrechenzentrum                 http://www.uni-bielefeld.de/hrz/
   Universität Bielefeld

From: Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/46329 (graphics/ImageMagick: visibility on Solaris with GCC4 still broken if using native ld)
Date: Fri, 13 Apr 2012 12:10:44 +0200

 On Fri, Apr 13, 2012 at 09:55:02AM +0000, Jörn Clausen wrote:
 >  On 13.04.12 11:45, Hans Rosenfeld wrote:
 >  >   graphics/ImageMagick built without problems in my SunOS 5.11 bulk build
 >  >   using lang/gcc46. Could it be that your gcc 4.7 is not configured
 >  >   correctly? I can't believe that a newer gcc4 suddenly lost support for
 >  >   the visibility attribute.
 >  
 >  It's the linker that does not support the code generated by GCC. As 
 >  mentioned, I use /usr/ccs/bin/ld, not binutils.

 So do I, it's the default in lang/gcc46 and lang/gcc44. And it works on
 Solaris 10, too.

From: =?ISO-8859-1?Q?J=F6rn_Clausen?= <joern.clausen@uni-bielefeld.de>
To: gnats-bugs@NetBSD.org
Cc: Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org>,
 solaris-pkg-people@NetBSD.org, gnats-admin@NetBSD.org, pkgsrc-bugs@NetBSD.org
Subject: Re: pkg/46329 (graphics/ImageMagick: visibility on Solaris with GCC4
 still broken if using native ld)
Date: Fri, 13 Apr 2012 15:54:23 +0200

 >   Gcc 4.x needs some variant of objdump to be able to detect whether the
 >   visibility attribute can be supported. This is why lang/gcc44 and
 >   lang/gcc46 set this on SunOS:
 >   CONFIGURE_ENV+=		OBJDUMP=/usr/sfw/bin/gobjdump

 I don't have that configured into my GCC. And as mentioned several time, 
 using /usr/sfw/bin is not an option for me.

 If you feel there is nothing to fix, please close this PR. I'll keep my 
 changes as a local patch.

 -- 
   Jörn Clausen                             joern.clausen@uni-bielefeld.de
   Hochschulrechenzentrum                 http://www.uni-bielefeld.de/hrz/
   Universität Bielefeld

From: Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/46329 (graphics/ImageMagick: visibility on Solaris with GCC4 still broken if using native ld)
Date: Fri, 13 Apr 2012 16:15:16 +0200

 On Fri, Apr 13, 2012 at 03:54:23PM +0200, Jörn Clausen wrote:
 > >  Gcc 4.x needs some variant of objdump to be able to detect whether the
 > >  visibility attribute can be supported. This is why lang/gcc44 and
 > >  lang/gcc46 set this on SunOS:
 > >  CONFIGURE_ENV+=		OBJDUMP=/usr/sfw/bin/gobjdump
 > 
 > I don't have that configured into my GCC. And as mentioned several time, 
 > using /usr/sfw/bin is not an option for me.

 Well, you could point to any other objdump if you like to do so. It is
 completely irrelevant how old it is or where it comes from. It is also
 _only_ ever used during the configure check that tries to determine
 whether visibility attributes can be supported. It is not built into
 the gcc package and not used in any way after the configure check.

 > If you feel there is nothing to fix, please close this PR. I'll keep my 
 > changes as a local patch.

 Honestly, I don't see why we should patch lots of packages to always
 disable the visibility attributes when it is actually supported by both
 the linker and the compiler. Also, I can't think of any reason why
 anyone would actively refuse to build gcc in a way that enables support
 for this.

>Unformatted:

Home	PR Database Search