bugmake - Bugs: bug #30914, Standard library search path not...

 
 

bug #30914: Standard library search path not configurable

Submitter:  Ed Martin <edman007>
Submitted:  Tue 31 Aug 2010 03:36:36 AM UTC
   
 
Severity:  3 - Normal Item Group:  Enhancement
Status:  None Privacy:  Public
Assigned to:  None Open/Closed:  Open
Component Version:  4.0 Operating System:  Any
Fixed Release:  None Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 20 Dec 2012 07:14:28 AM UTC, comment #2: 

Clearing .SYSLIBDIRS now follows documented behavior; See https://bitbucket.org/abutcher/gmake-ajb/commits/000e435

Adam Butcher <abutcher>
Wed 19 Dec 2012 10:45:47 PM UTC, comment #1: 

I have hit this in the context of cross-compilation, where a dependency problem was undiagnosed due to a system library being found rather than the correct target system lib.  The makefile had a bug whereby the correct sysroot lib paths for the target system were not added to vpath for %.so and %.a.  This caused the makefile to work okay on systems where the dependent lib happened to be installed natively on the build system but fail to find prerequisites if that wasn't the case.

For cross-compilation it is almost never useful to search /lib and /usr/lib for library dependencies.   I have made a patch against the latest CVS which adds support for a new special variable '.SYSLIBDIRS' which, if set, overrides the hardcoded build-time built-ins.  The patch also adds support for synthesising default values into this variable by specifying an alternative sysroot via the CROSS_SYSROOT environment variable.

The patch is available at https://bitbucket.org/abutcher/gmake-ajb/commits/e484dc0   The make.texi is updated with usage info.


Adam Butcher <abutcher>
Tue 31 Aug 2010 03:36:36 AM UTC, original submission:  

for rules like this:

foo: -lbar

According to the docs:

> When a prerequisite's name has the form ‘-lname’, make handles it specially by searching for the file libname.so, and, if it is not found, for the file libname.a in the current directory, in directories specified by matching vpath search paths and the VPATH search path, and then in the directories /lib, /usr/lib, and prefix/lib (normally /usr/local/lib, but MS-DOS/MS-Windows versions of make behave as if prefix is defined to be the root of the DJGPP installation tree).


So, /lib, /usr/lib and $libdir (from the configure script) get compiled in as part of the search path. However many distros use lib64 and thus the search path should be /lib64 and /usr/lib64 ($libdir is confirgurable, so I don't that that matters much). But from what I can tell there is no way, short of patching, to remove /lib and /usr/lib from that search path (causes problems, say building a 64-bit app with a 32-bit version available, unlike gcc, make wouldn't just skip over it because it is the wrong arch). And more importantly there is no way to add multiple directories to this path, thus you can't put /lib64, /usr/lib64 and /usr/local/lib64 in the search path (or even /usr/local/lib if make was installed into /usr [unless you explictly set $libdir to /usr/local/lib, which goes against what the configure script says that directory is used for]).

Make should not use the --libdir config argument to set this path (it goes against what the config docs say '--libdir=DIR object code libraries [EPREFIX/lib]'). A better solution might be if the configure script offered a method to set the path outright (such as --standard-path=/lib64:/usr/lib64:/usr/local/lib64 ) and this could then default to something reasonable, possibly including the common lib64 variant when when it exists on an x86_64 build.

Ed Martin <edman007>

 

(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 abutcher (Posted a comment)
  • -email is unavailable- added by edman007 (Submitted the item)
  •  

    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-d3ae.
    Corresponding source code