Opened 12 years ago

Closed 11 years ago

#94 closed defect (worksforme)

FindBin failes to find lib64 modules on x86_64 systems

Reported by: human Owned by:
Version: 2.x Keywords: lib64 FindBin
Cc: nkadel@…

Description

A number of the scripts have a hard-coded 'lib' in the FindBin? statement, which fails on systems with lib64 installation set in the "configure" statements. This causes problems especially with RPM package installations, such as the new one at RPMforge.

I have a patch file for this, based on the older patches from the RPMforge 2.12.1 package.

Attachments (1)

mrtg-2.16.4-lib64.patch (3.0 KB) - added by human 12 years ago.
Uses @@lib@@ instead of lib in FindBin? for lib64 systems.

Download all attachments as: .zip

Change History (7)

Changed 12 years ago by human

Uses @@lib@@ instead of lib in FindBin? for lib64 systems.

comment:1 Changed 12 years ago by oetiker

hmmm and who takes care of replacing @@lib@@ with lib64 ? these are no .in files ... ?

comment:2 Changed 12 years ago by human

I see your point. The RedHat? RPM's apply the patch, and then replace the @@lib@@ with '%libdir' as part of the '%install' process, after running 'make install' to the temporarary RPM direcotory in /var/tmp/.

In order to support 64-bit operation, would you consider accepting a patch to Makefile.in and moving the mrtg, cfgmaker, etc. scripts to mrtg.in, cfgmaker.in, etc.? Or would you more easily accept a Makefile.in change that modified the scripts as part of the installation process?

comment:3 Changed 12 years ago by oetiker

hmmm ok, I guess this would be ok. BUT why not make the library path completely arbitrary ? aka configurable ... add it BEFORE what is there now, in that way the *.in version would work too while developing the stuff ...

comment:4 Changed 12 years ago by human

I agree with configurability. I'd do something like you do with the "GRAPHFMT=" settings and the "#*/*perl" lines, but instead of editing the files in place, I'd edit them from an "mrtg.in" script to an "mrtg" script.

In fact, it would make sense to move those setting modifications as well to the "make" process.

comment:5 Changed 12 years ago by oetiker

my only concern is, that I really want to have be able to run mrtg while developing ...

so from a convenience point of view the *.in route is not all that appealing ... inplace editing is much more so ...

comment:6 Changed 11 years ago by oetiker

  • Resolution set to worksforme
  • Status changed from new to closed

I can not find this problem on my systems, so please submit a proper patch if you like to see this integrated ... I am closing the bug for now.

Note: See TracTickets for help on using tickets.
 

NOTE: The content of this website is accessible with any browser. The graphical design though relies completely on CSS2 styles. If you see this text, this means that your browser does not support CSS2. Consider upgrading to a standard conformant browser like Mozilla Firefox or Opera but also Apple's Safari or KDE's Konqueror for example.