From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13313 invoked by alias); 26 Feb 2009 22:10:01 -0000 Received: (qmail 13304 invoked by uid 22791); 26 Feb 2009 22:09:59 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,HK_OBFDOM,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 26 Feb 2009 22:09:50 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n1QM9mVX024263 for ; Thu, 26 Feb 2009 17:09:48 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n1QM9mdP021950 for ; Thu, 26 Feb 2009 17:09:49 -0500 Received: from localhost.localdomain (vpn-14-57.rdu.redhat.com [10.11.14.57]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n1QM9l6p018496 for ; Thu, 26 Feb 2009 17:09:48 -0500 Date: Thu, 26 Feb 2009 22:10:00 -0000 From: Kevin Buettner To: insight@sourceware.org Subject: Re: Build CVS insight on x86_64 Message-ID: <20090226150946.44778603@redhat.com> In-Reply-To: <496DC50C.1080802@analog.com> References: <496DC50C.1080802@analog.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact insight-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: insight-owner@sourceware.org X-SW-Source: 2009-q1/txt/msg00014.txt.bz2 On Wed, 14 Jan 2009 18:57:16 +0800 Jie Zhang wrote: > Does anyone succeed in building CVS insight on x86_64? I tried a native > build today on Debian unstable AMD64. But it failed. The error is: > > gcc -pipe -shared -o libitk3.3.so itk_cmds.o itk_option.o > itk_archetype.o itk_util.o itkStubInit.o -lX11 > -L/home/jie/sources/insight/build/tcl/unix -ltclstub8.4 > -L/home/jie/sources/insight/build/tk/unix -ltkstub8.4 > -L/home/jie/sources/insight/build/itcl/itcl -litclstub3.3 > /usr/bin/ld: itk_cmds.o: relocation R_X86_64_32 against `a local symbol' > can not be used when making a shared object; recompile with -fPIC > itk_cmds.o: could not read symbols: Bad value > collect2: ld returned 1 exit status > > But it on i386 host is OK. But the insight 6.8 release on x86_64 is also OK. I've spent some time looking into this. At configuration time, the itcl and itk packages compute a CFLAGS setting for the generated Makefile. For some hosts, it's critcal that these settings be used. If you look at resultant Makefile in itcl/{itcl,itk} (in your build directory), you'll see lines which look like this: CFLAGS = -g -O2 ${CFLAGS_DEFAULT} ${CFLAGS_WARNING} ${SHLIB_CFLAGS} COMPILE = $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) That CFLAGS line was generated from this line in Makefile.in: CFLAGS = @CFLAGS@ SHLILB_CFLAGS has that all important -fPIC option mentioned in the error message. The only places that it appears in the Makefile are where it is being assigned and in that CFLAGS setting noted above, but only as a result of a substitution. Thus, it's critically important that the itcl- or itk-specific version of CFLAGS be used when compiling a file. What is happening is that the top level Makefile has its own set of CFLAGS that it passes down to each of the sub-makes. This CFLAGS setting is overriding the itcl- and itk-specific CFLAGS settings. That means that those critically important itcl- and itk-specific CFLAGS definitions are *not* being used. The reason that it works on a 32-bit x86 host, but not on x86_64 is because the x86 host doesn't seem to _really_ need the -fPIC option in order to compile successfully. I've checked the x86 build without my patch below and it does not use -fPIC, even though -fPIC is specified for SHLIB_CFLAGS in the Makefile. I have a patch for this problem; see below. What my patch does is rename CFLAGS to either ITCL_CFLAGS or ITK_CFLAGS. It then uses these new makefile variables in the definition of COMPILE. Note that CFLAGS is still present for COMPILE. This is important so that any build specific optimization switches (or whatever) get passed from the top down to these packages. Keith, is this okay to commit? * itcl/Makefile.in (ITCL_CFLAGS): Renamed from CFLAGS. (COMPILE): Use ITCL_CFLAGS in addition to CFLAGS. * itk/Makefile.in (ITK_CFLAGS): Renamed from CFLAGS. (COMPILE): Use ITK_CFLAGS in addition to CFLAGS. Index: itcl/Makefile.in =================================================================== RCS file: /cvs/src/src/itcl/itcl/Makefile.in,v retrieving revision 1.7 diff -u -p -r1.7 Makefile.in --- itcl/Makefile.in 23 Jul 2008 22:44:50 -0000 1.7 +++ itcl/Makefile.in 26 Feb 2009 21:36:47 -0000 @@ -145,8 +145,8 @@ CONFIG_CLEAN_FILES = @CONFIG_CLEAN_FILES CPPFLAGS = @CPPFLAGS@ LIBS = @PKG_LIBS@ @LIBS@ AR = @AR@ -CFLAGS = @CFLAGS@ -COMPILE = $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) +ITCL_CFLAGS = @CFLAGS@ +COMPILE = $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) $(ITCL_CFLAGS) #======================================================================== # Start of user-definable TARGETS section Index: itk/Makefile.in =================================================================== RCS file: /cvs/src/src/itcl/itk/Makefile.in,v retrieving revision 1.7 diff -u -p -r1.7 Makefile.in --- itk/Makefile.in 23 Jul 2008 22:44:51 -0000 1.7 +++ itk/Makefile.in 26 Feb 2009 21:36:47 -0000 @@ -170,8 +170,8 @@ CONFIG_CLEAN_FILES = @CONFIG_CLEAN_FILES CPPFLAGS = @CPPFLAGS@ LIBS = @PKG_LIBS@ @LIBS@ AR = @AR@ -CFLAGS = @CFLAGS@ -COMPILE = $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) +ITK_CFLAGS = @CFLAGS@ +COMPILE = $(CC) $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) $(ITK_CFLAGS) #======================================================================== # Start of user-definable TARGETS section