From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4255 invoked by alias); 10 Apr 2003 18:03:16 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 4231 invoked from network); 10 Apr 2003 18:03:15 -0000 Received: from unknown (HELO corp148mr2.mcgraw-hill.com) (198.45.18.163) by sources.redhat.com with SMTP; 10 Apr 2003 18:03:15 -0000 Received: by corp148mr2.mcgraw-hill.com (Switch-3.0.3/Switch-3.0.0) with SMTP id h3AI2bVk003255; Thu, 10 Apr 2003 14:02:37 -0400 (EDT) X-Lotus-FromDomain: FIS@MCGRAW-HILL From: robert_f_sharp@platts.com To: Nick Clifton cc: binutils@sources.redhat.com Message-ID: <85256D04.0062ACB7.00@corpnj148ls01.mcgraw-hill.com> Date: Thu, 10 Apr 2003 18:03:00 -0000 Subject: Re: ld core dump Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-SW-Source: 2003-04/txt/msg00252.txt.bz2 Thanks Nick I will experiment with your suggestions for diagnostics and see what I can find. I have tried to use GNU tools (gcc, ld) completely. The build will compile and link the 64bit smbd program etc but I think the problem is with building 64bit shared objects . I think the linker should just look at the ELF headers on the input files and determine the mode, 32 or 64 bit. I will look for a 64bit linker directive for shared objects. I guess my main problem is ld that ld turns it's toes up (core dumps) and that introduces the question of how much can you trust its error messages, I would have thought it should be a little more robust. Robert S. Nick Clifton on 09/04/2003 16:37:56 To: Robert F Sharp/ST/FIS@FIS cc: binutils@sources.redhat.com Subject: Re: ld core dump Hi Robert, > luck. I have included the latest output. The one thing that attracts my > attention is the output, sparc, not as it should be, sparcv9. Is it trying to > link libnss_winbind.so as a 32bit (sparc?) oject? Probably. It sounds like you have a 32bit sparc targeted linker, so it is trying to create a 32bit sparc executable, and it gets rather confused when you give it 64bit libraries... I am not a sparc expert, so I am not sure whether there is a different linker to create 32bit and 64bit executable or just one linker and a command line switch. (Or maybe there is only one linker and the linker is supposed to be clever and work out which kind of binary it is supposed to create from its input files). > bash-2.05$ make > Using FLAGS = -O -m64 -I./popt -Iinclude -I./include -I./ubiqx -I./smbwrapper Could you make "make" tell you the *exact* command line that it is executing ? It may be that there are some strange switches in there, or maybe a 32bit object file... Also could you add "-v" to the command line ? I assume that you are using gcc to drive the linker, so passing "-v" to gcc will cause it to print out the command line that it is using to invoke the linker Cheers Nick