[cups.development] [RFE] STR #2119: configure search directories for shared libraries
Bernd Krumböck
b.krumboeck at rewe-group.at
Thu Nov 23 13:57:31 PST 2006
Michael Sweet wrote:
>
> First, that behavior is significantly different than what is provided
> on HP-UX 11.00, which only uses the library paths if you pass "+b:".
>
You're right the behavior has changed. I checked the man page for HP-UX
11.11 PA-RISC and HP-UX 11.23 IA64 (see below). :(
Seems that my problem exists on both platforms, it simple didn't hurt me
until now.
HP-UX 11.11 (PA-RISC):
+b path_list Specify a colon-separated list of directories
(embedded path) to be searched at program run-time
to locate shared libraries needed by the
executable output file that were specified with
either the -l or -l: option.
An argument consisting of a single colon (:)
indicates that ld should build the list using all
the directories specified by the -L option and the
LPATH environment variable (see the +s option).
For 32-bit links, if multiple +b options appear on
the link line, the FIRST one specified is
recorded. Also, a double colon (::) is
interpreted as location in which libraries are
found at link time.
For 64-bit links, the LAST of multiple +b options
is recorded in the output file. A double colon
(::) does not have special meaning (i.e. treated
as NULL entry).
HP-UX 11.23 (IA64):
+b path_list Specify a colon-separated list of directories to
be searched at program run-time to locate shared
libraries needed by the executable output file
that were specified with either the -l or -l:
options. This list of directories becomes the
embedded path. If either +b is not used or if you
specify a single colon (:) as the argument, ld
builds an embedded path using all the directories
specified by the -L option(s) and the LPATH
environment variable (see the +s option).
> Second, doing so is not safe since we are using:
>
> -L../cups -lcups
>
> to link to the CUPS library in the CUPS executables. That would
> mean that "../cups" would be bound into the search path for libraries,
> leading to a significant security hole in your binaries!
>
That's the reason why I don't like my simple hack.
Is extending ld command (this takes years) the only way to solve or do you
have some other suggestions?
At least I'm searching for a workaround/solution which doesn't need source
code modifications. (maybe a special environment variable?)
best regards!
Bernd
More information about the cups
mailing list