bugmake - Bugs: bug #16276, x86_64 link library paths are not...

 
 

bug #16276: x86_64 link library paths are not correct when specified as dependencies

Submitter:  John DeFranco <jdefranco>
Submitted:  Wed 05 Apr 2006 11:30:50 PM UTC
   
 
Severity:  3 - Normal Item Group:  Enhancement
Status:  None Privacy:  Public
Assigned to:  None Open/Closed:  Open
Component Version:  None Operating System:  None
Fixed Release:  None Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 12 Nov 2007 09:32:57 PM UTC, comment #1: 

Is it possible to create a new special variable, such as LPATH (like VPATH) or .LIBPATHS (like .LIBPATTERNS), to specify the directories to search for the system link libraries?

Currently, I'm using vpath, which works fine:

ifeq (x86_64,$(shell uname -i))
  vpath %.so $(wildcard lib/lib*) /lib64 /usr/lib64 /usr/local/lib64
  vpath %.a  $(wildcard lib/lib*) /lib64 /usr/lib64 /usr/local/lib64
else
  vpath %.so $(wildcard lib/lib*)
  vpath %.a  $(wildcard lib/lib*)
endif

Steve Siano <ssiano>
Wed 05 Apr 2006 11:30:50 PM UTC, original submission:  

%% John DeFranco <defranco@cup.hp.com> writes:

  jd> On x86_64 systems it would seem that the search path for
  jd> link libraries should be : /lib64, /usr/lib64, /lib, 
  jd> /usr/lib, etc. If not you end up
  jd> getting the 32 bit libraries included first and then a
  jd> link error. For
  jd> example (cut down to only include the pertinent segments):
  jd> cc   -g -o test  o cl_rba_uds_test.o /usr/lib/libm.so \
  jd>         /usr/lib/libdl.so   objs/linux/debug/cl_chain.o \
  jd>          -Lobjs/linux/debug -lmylib
  jd> /usr/lib/libm.so: could not read symbols: File in wrong
  jd> format collect2: ld returned 1 exit status
  jd> In this case -lm and -ldl where sepecified as dependencies
  jd> in the makefile. The proper path for /usr/lib/libm.so
  jd> and /usr/lib/libdl.so should have been /usr/lib64/libm.so
  jd> and /usr/lib64/libdl.so.

It's not clear to me how make should manage this.  After all there are many issues such as (a) cross-compilation, (b) different platforms using different models for 64-bit support, etc.

I don't know that GNU make can really do much with this, from an
autoconf standpoint for example.

My first instinct is to say that it is up to your distribution provider to configure GNU make properly for your system; if the default library search path is not correct for that distribution then it should be their responsibility to configure it properly.


That being said, it's not so easy to set up the default value for this path!  I've checked the code and there's no "configure" option or similar that can be set when GNU make is built to override the default search path.  Offering such an option might well be an enhancement that would make sense to put into the GNU make distribution.

Please file a bug against the GNU make project on the Savannah web site, marked as either "Enhancement" or "Build/Install", so we don't lose track of this.

John DeFranco <jdefranco>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ssiano (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code