%% John DeFranco <[EMAIL PROTECTED]> writes:

  jd> On x86_64 systems it would seem that the search path for link libraries 
  jd> should be : /lib64, /usr/lib64, /lib, /usr/lib, etc. If not you end up 
  jd> getting the 32 bit libraries included first and then a 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/md80.cup.hp.com/debug/cl_chain.o \
  jd>          -Lobjs/linux/debug -lmylib
  jd> /usr/lib/libm.so: could not read symbols: File in wrong format
  jd> collect2: ld returned 1 exit status

  jd> In this case -lm and -ldl where sepecified as dependencies in the 
  jd> makefile. The proper path for /usr/lib/libm.so and /usr/lib/libdl.so 
  jd> should have been /usr/lib64/libm.so 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.

Also, if you file a bug with your distribution vendor please put a link
to that bug in the Savannah report so we can track their response (I'll
be much more likely to fix this if distributions agree with me that it's
the right solution :-)).

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[EMAIL PROTECTED]>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist


_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Reply via email to