|
|
|
|
|
|
| Author |
Message |
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
 Posted: Tue May 28, 2002 3:16 am Post subject:
Re: Why don't we search /usr/local/lib and /usr/local/include by default?
|
|
|
Greg 'groggy' Lehey wrote:
| Quote: | I've just had a question from some friends in the Linux space about
why we install additional libraries in /usr/local/lib and their header
files in /usr/local/include, but gcc by default only searches
/usr/local/libexec and /usr/local/lib for libraries and /usr/include
for header files. They think that this is inconsistent, and I tend to
agree. What speaks against adding the /usr/local directories to the
specs files for gcc?
|
The fact that ldconfig is assinine, and prevents loading the shared
libraries at runtime, even if they are found at link time, for one,
because ld.so doesn't fall back to searching known directories, if
it fails to find libraries in cache, unless you set LD_LIBRARY_PATH
explicitly.
Or in shorting terms: "Doing that doesn't actually work".
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
 |
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Tue May 28, 2002 3:16 am Post subject:
Re: Why don't we search /usr/local/lib and /usr/local/include by default?
|
|
|
Terry Lambert wrote:
| Quote: | Or in shorter terms: "Doing that doesn't actually work".
|
Ignore everything but this part; I thought it was a -chat posting.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Antoine Beaupre
*nix forums beginner
Joined: 28 May 2002
Posts: 3
|
| Posted: Tue May 28, 2002 11:59 am Post subject:
Re: Why don't we search /usr/local/lib and /usr/local/include by default?
|
|
|
We could still make the ports system try to use libraries in
/usr/local/lib too by default since most third party apps have
dependencies on other third-party apps.
The way I usually do it is:
CONFIGURE_ENV+= CPPFLAGS="-I${LOCALBASE}/include" \
LDFLAGS="-L${LOCALBASE}/lib" \
CFLAGS="-I${LOCALBASE}/include ${CFLAGS}" \
CXXFLAGS="-I${LOCALBASE}/include ${CXXFLAGS}"
or something like that. I think a lot of ports have something like that
in there somewhere.
A.
Le mardi 28 mai 2002, à 01:15 AM, Terry Lambert a écrit :
| Quote: | Terry Lambert wrote:
Or in shorter terms: "Doing that doesn't actually work".
Ignore everything but this part; I thought it was a -chat posting.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
|
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
David O'Brien
*nix forums beginner
Joined: 28 May 2002
Posts: 1
|
| Posted: Tue May 28, 2002 1:42 pm Post subject:
Re: Why don't we search /usr/local/lib and /usr/local/include by default?
|
|
|
On Tue, May 28, 2002 at 02:34:44PM +0930, Greg 'groggy' Lehey wrote:
| Quote: | I've just had a question from some friends in the Linux space about
why we install additional libraries in /usr/local/lib and their header
files in /usr/local/include, but gcc by default only searches
/usr/local/libexec and /usr/local/lib for libraries and /usr/include
|
The system GCC searching any part of /usr/local is a bug. It is not
[ports] PREFIX clean. (you have typos above about /usr/local/libexec
don't you?)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Peter Wemm
*nix forums Guru Wannabe
Joined: 11 Apr 2002
Posts: 113
|
| Posted: Tue May 28, 2002 3:29 pm Post subject:
Re: Why don't we search /usr/local/lib and /usr/local/include by default?
|
|
|
"Greg 'groggy' Lehey" wrote:
| Quote: | I've just had a question from some friends in the Linux space about
why we install additional libraries in /usr/local/lib and their header
files in /usr/local/include, but gcc by default only searches
/usr/local/libexec and /usr/local/lib for libraries and /usr/include
for header files. They think that this is inconsistent, and I tend to
agree. What speaks against adding the /usr/local directories to the
specs files for gcc?
|
gcc and ld do not look at /usr/local at all. We set /usr/local/lib
in the ld-elf.so.1 search path, but ld-elf.so.1 != ld. ld actually looks
for *.a and *.so, while ld-elf.so.1 looks for *.so.*
We have folks who have ports elsewhere than /usr/local. Eg: when
/usr/local is NFS shared from a netapp or something. If ports depend on gcc
assuming that ports are in /usr/local, then they stop working when they are
put elsewhere (/opt, /home/local, whatever) since they'd suddenly need to
explicitly add -I and -L paths.
Cheers,
-Peter
--
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Tue May 28, 2002 5:18 pm Post subject:
Re: Why don't we search /usr/local/lib and /usr/local/include by default?
|
|
|
David O'Brien wrote:
| Quote: | On Tue, May 28, 2002 at 02:34:44PM +0930, Greg 'groggy' Lehey wrote:
I've just had a question from some friends in the Linux space about
why we install additional libraries in /usr/local/lib and their header
files in /usr/local/include, but gcc by default only searches
/usr/local/libexec and /usr/local/lib for libraries and /usr/include
The system GCC searching any part of /usr/local is a bug. It is not
[ports] PREFIX clean. (you have typos above about /usr/local/libexec
don't you?)
|
Potentialy, the ports .mk files, when they observe PREFIX, should
reset the entire include and library path, so this really should
not be an issue.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Tue May 28, 2002 5:31 pm Post subject:
Re: Why don't we search /usr/local/lib and /usr/local/include by default?
|
|
|
Antoine Beaupre wrote:
| Quote: | We could still make the ports system try to use libraries in
/usr/local/lib too by default since most third party apps have
dependencies on other third-party apps.
The way I usually do it is:
CONFIGURE_ENV+= CPPFLAGS="-I${LOCALBASE}/include" \
LDFLAGS="-L${LOCALBASE}/lib" \
CFLAGS="-I${LOCALBASE}/include ${CFLAGS}" \
CXXFLAGS="-I${LOCALBASE}/include ${CXXFLAGS}"
or something like that. I think a lot of ports have something like that
in there somewhere.
|
The resulting binaries still do not work, unless LD_LIBRARY_PATH
is set, or there is an intervening run of "ldconfig". They fail
to find shared libraries at runtime, installed after boot but
before link (the libraries are found at link time, just not at
runtime).
It seems to me that either the ld should fail to find the libraries
at link time if it's not going to find them at runtime, or it should
find them at runtime if it found them at link time. But ldconfig is
more than it should be... it's more of a csh "rehash" of the path
hash, when it should probably be a tcsh "rehash": search the hash
first, and on failure, search the PATH (adding to the hash automatically
on a success would be the wrong thing to do, but finding it would not
be).
It's really annoying to have one algorithm for linking and another
for running. I don't really understand the value of this assymetry;
I guess it's intended to allow you to build without properly
installing libraries on the build system. In practice, however, it
is never really done this way in "ports" or other places, or the
packages builds would not have to take place on virtually "clean"
systems in order to ensure that a dependency is not missed.
I put this one down to the lack of care taken in preparation of ports,
to ensure that paths are limited on install and build, so that it should
be possible to use a different PREFIX per port, and build simultaneously,
without it "finding" things it shouldn't. If *that* were possible,
then automatically finding headers and libraries in /usr/local during
the build would *definitely* be the wrong thing to do: the local system
would effect the dependency satisfaction of a package build when it
shouldn't.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Antoine Beaupre
*nix forums beginner
Joined: 28 May 2002
Posts: 3
|
| Posted: Tue May 28, 2002 6:23 pm Post subject:
Re: Why don't we search /usr/local/lib and /usr/local/include by default?
|
|
|
Le mardi 28 mai 2002, à 03:31 PM, Terry Lambert a écrit :
| Quote: | Antoine Beaupre wrote:
We could still make the ports system try to use libraries in
/usr/local/lib too by default since most third party apps have
dependencies on other third-party apps.
The way I usually do it is:
CONFIGURE_ENV+= CPPFLAGS="-I${LOCALBASE}/include" \
LDFLAGS="-L${LOCALBASE}/lib" \
CFLAGS="-I${LOCALBASE}/include ${CFLAGS}" \
CXXFLAGS="-I${LOCALBASE}/include ${CXXFLAGS}"
or something like that. I think a lot of ports have something like that
in there somewhere.
The resulting binaries still do not work, unless LD_LIBRARY_PATH
is set, or there is an intervening run of "ldconfig". They fail
to find shared libraries at runtime, installed after boot but
before link (the libraries are found at link time, just not at
runtime).
|
Well right now this does work because (I think) ldconfig *is* ran by
pkg_add (or make install) when installing the port, if it contains
shared libs.
I'm not sure I agree that searching /usr/local by default is violating
PREFIX anymore, since /usr/local is usually our default prefix
(exception made of X) for ports.
The initial problem is that we have 4 PREFIXes in common installs: /,
/usr, /usr/local and /usr/X11R6. How is a port supposed to find a
dependent package in there? How can it pretend to be PREFIX-independant
when the ports depending on it can be installed in one of these 4
different PREFIXes?
/usr/local is an interesting abstraction. It allows us to distinguish
base from ports, but it's basically a hack. We have "ports" (sendmail,
openssh) in base, which blurs this line (and creates periodic threads on
various mailing lists). Ideally, we should be able to have all of our
software cleanly packaged, base would only be "software packages written
and/or maintained by FreeBSD", and would be a simple flag in the package.
Ideally, /usr/local should go away. Packages should install in /usr by
default. But the ports system would need a bigger fence around it to
expose /usr this way, IMHO.
Unfortunatly, we're stuck with /usr/local, and I think that as soon as a
port depends on another *port* its linking search path should be hacked
to include the prefix of that dependent port.
No, I don't have any patches. ;)
A.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Greg 'groggy' Lehey
*nix forums beginner
Joined: 28 May 2002
Posts: 1
|
| Posted: Tue May 28, 2002 10:12 pm Post subject:
Re: Why don't we search /usr/local/lib and /usr/local/include by default?
|
|
|
On Tuesday, 28 May 2002 at 8:42:48 -0700, David O'Brien wrote:
| Quote: | On Tue, May 28, 2002 at 02:34:44PM +0930, Greg 'groggy' Lehey wrote:
I've just had a question from some friends in the Linux space about
why we install additional libraries in /usr/local/lib and their header
files in /usr/local/include, but gcc by default only searches
/usr/local/libexec and /usr/local/lib for libraries and /usr/include
The system GCC searching any part of /usr/local is a bug. It is not
[ports] PREFIX clean.
|
So how would you recommend we solve the issue?
| Quote: | (you have typos above about /usr/local/libexec don't you?)
|
Yes, sorry.
Greg
--
See complete headers for address and phone numbers
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Tue May 28, 2002 11:04 pm Post subject:
Re: Why don't we search /usr/local/lib and /usr/local/include by default?
|
|
|
Greg 'groggy' Lehey wrote:
| Quote: | The system GCC searching any part of /usr/local is a bug. It is not
[ports] PREFIX clean.
So how would you recommend we solve the issue?
|
I hesitate to mention this.
But there are two obvious ways:
1) Add the expectation paths for things to the default, and
if someone puts the libraries or headers in a non-default
place, it's their responsibility. This would also require
changing the ldconfig cache to be "hints", rather than
"the only path".
2) Make the compiler use the ldconfig cache path prefixes;
then everything would "just work".
#2 is harder. I also don't think it's what you really want. The
Linux people who are complaining are probably also complaining
about including one include file not including all include files,
and the lack of a /usr/include/linux/.
PS: I put number 2 last on purpose because I really don't like it.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Peter Wemm
*nix forums Guru Wannabe
Joined: 11 Apr 2002
Posts: 113
|
| Posted: Tue May 28, 2002 11:25 pm Post subject:
Re: Why don't we search /usr/local/lib and /usr/local/include by default?
|
|
|
"Greg 'groggy' Lehey" wrote:
| Quote: | On Tuesday, 28 May 2002 at 8:42:48 -0700, David O'Brien wrote:
On Tue, May 28, 2002 at 02:34:44PM +0930, Greg 'groggy' Lehey wrote:
I've just had a question from some friends in the Linux space about
why we install additional libraries in /usr/local/lib and their header
files in /usr/local/include, but gcc by default only searches
/usr/local/libexec and /usr/local/lib for libraries and /usr/include
The system GCC searching any part of /usr/local is a bug. It is not
[ports] PREFIX clean.
So how would you recommend we solve the issue?
|
Err, what issue? gcc does not search /usr/local anywhere.
peter@daintree[6:22pm]/tmp-106> ls -l /usr/local/include/jerror.h
-r--r--r-- 1 root wheel 13936 May 28 16:52 /usr/local/include/jerror.h
peter@daintree[6:22pm]/tmp-107> cc -c foo.c
foo.c:1:20: jerror.h: No such file or directory
peter@daintree[6:22pm]/tmp-108> grep jerror foo.c
#include <jerror.h>
and
eter@daintree[6:23pm]/tmp-113> ls -l /usr/local/lib | grep libxml
-rw-r--r-- 1 root wheel 523838 Apr 17 04:23 libxml.a
lrwxr-xr-x 1 root wheel 11 May 21 19:08 libxml.so@ -> libxml.so.5
-rwxr-xr-x 1 root wheel 495202 Apr 17 04:23 libxml.so.5*
peter@daintree[6:23pm]/tmp-114> cc -o foo foo.c -lxml
/usr/libexec/elf/ld: cannot find -lxml
Yes, /usr/local/lib is on my ldconfig path.
peter@daintree[6:24pm]/tmp-120> ldconfig -r | head -2
/var/run/ld-elf.so.hints:
search directories: /usr/lib:/usr/lib/compat:/usr/X11R6/lib:/usr/local/lib
This is working exactly as designed. Your email suggests you found a bug
in the implementation of this.. Or are you complaining about the design
itself?
| Quote: | (you have typos above about /usr/local/libexec don't you?)
Yes, sorry.
Greg
|
Cheers,
-Peter
--
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Greg 'groggy' Lehey
*nix forums beginner
Joined: 29 May 2002
Posts: 1
|
| Posted: Wed May 29, 2002 1:05 am Post subject:
Re: Why don't we search /usr/local/lib and /usr/local/include by default?
|
|
|
On Tuesday, 28 May 2002 at 18:25:44 -0700, Peter Wemm wrote:
| Quote: | "Greg 'groggy' Lehey" wrote:
On Tuesday, 28 May 2002 at 8:42:48 -0700, David O'Brien wrote:
On Tue, May 28, 2002 at 02:34:44PM +0930, Greg 'groggy' Lehey wrote:
I've just had a question from some friends in the Linux space about
why we install additional libraries in /usr/local/lib and their header
files in /usr/local/include, but gcc by default only searches
/usr/local/libexec and /usr/local/lib for libraries and /usr/include
The system GCC searching any part of /usr/local is a bug. It is not
[ports] PREFIX clean.
So how would you recommend we solve the issue?
Err, what issue? gcc does not search /usr/local anywhere.
|
Correct. As obrien observed, I mean to say
| Quote: | gcc by default only searches /usr/libexec and /usr/lib for
libraries...
The system GCC searching any part of /usr/local is a bug. It is not
[ports] PREFIX clean.
peter@daintree[6:22pm]/tmp-106> ls -l /usr/local/include/jerror.h
-r--r--r-- 1 root wheel 13936 May 28 16:52 /usr/local/include/jerror.h
peter@daintree[6:22pm]/tmp-107> cc -c foo.c
foo.c:1:20: jerror.h: No such file or directory
peter@daintree[6:22pm]/tmp-108> grep jerror foo.c
#include <jerror.h
and
eter@daintree[6:23pm]/tmp-113> ls -l /usr/local/lib | grep libxml
-rw-r--r-- 1 root wheel 523838 Apr 17 04:23 libxml.a
lrwxr-xr-x 1 root wheel 11 May 21 19:08 libxml.so@ -> libxml.so.5
-rwxr-xr-x 1 root wheel 495202 Apr 17 04:23 libxml.so.5*
peter@daintree[6:23pm]/tmp-114> cc -o foo foo.c -lxml
/usr/libexec/elf/ld: cannot find -lxml
Yes, /usr/local/lib is on my ldconfig path.
|
Right, but ldconfig is used only at run time. gcc -v shows (not
surprisingly) that the /usr/local hierarchy is ignored.
| Quote: | peter@daintree[6:24pm]/tmp-120> ldconfig -r | head -2
/var/run/ld-elf.so.hints:
search directories: /usr/lib:/usr/lib/compat:/usr/X11R6/lib:/usr/local/lib
This is working exactly as designed. Your email suggests you found a bug
in the implementation of this.. Or are you complaining about the design
itself?
|
I'm complaining about the implementation. Since the Ports Collection
installs by default in /usr/local, it seems reasonable to at least put
these directories at the end of the search paths for header files and
libraries.
| Quote: | (you have typos above about /usr/local/libexec don't you?)
Yes, sorry.
|
This is where you put obrien's reference to my typos.
Greg
--
See complete headers for address and phone numbers
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Greg 'groggy' Lehey
*nix forums beginner
Joined: 29 May 2002
Posts: 1
|
| Posted: Wed May 29, 2002 2:50 am Post subject:
Re: Why don't we search /usr/local/lib and /usr/local/include by default?
|
|
|
On Tuesday, 28 May 2002 at 22:14:53 -0600, Warner Losh wrote:
| Quote: | In message: <20020529122327.C82424@wantadilla.lemis.com
"Greg 'groggy' Lehey" <grog@FreeBSD.ORG> writes:
I'm complaining about the implementation. Since the Ports Collection
installs by default in /usr/local, it seems reasonable to at least put
these directories at the end of the search paths for header files and
libraries.
It is working as designed. /usr/local/* isn't searched by default,
and never have been in BSD.
|
"We do it this way because our grandfathers did it this way"?
| Quote: | Just because Linux is lame
|
I think that's a rather blanked statement.
| Quote: | doesn't mean that we should be too.
|
No, but I can see (and have presented) good reasons.
| Quote: | We shouldn't search /usr/local by default because PREFIX can be set
to anything.
|
It doesn't do any harm even in that case.
| Quote: | We shouldn't search it because that may break other things.
|
What?
Greg
--
See complete headers for address and phone numbers
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Marcel Moolenaar
*nix forums Guru Wannabe
Joined: 03 Apr 2002
Posts: 120
|
| Posted: Wed May 29, 2002 3:59 am Post subject:
Re: Why don't we search /usr/local/lib and /usr/local/include by default?
|
|
|
On Wed, May 29, 2002 at 12:23:27PM +0930, Greg 'groggy' Lehey wrote:
| Quote: |
I'm complaining about the implementation. Since the Ports Collection
installs by default in /usr/local, it seems reasonable to at least put
these directories at the end of the search paths for header files and
libraries.
|
Putting /usr/local at the end of the search path by default does not
yield the same result as putting -I/usr/include on the command line
when there's a conflict (db.h and/or ndbm.h come to mind), because
-I is search before the default (system) search path.
On the other hand, putting /usr/include up front by default is probably
just broken by design.
I think adding /usr/include to the default search path is based on
the optimistic assumption that there's no conflict. This may cause
unexpected random failures when there is a conflict that the user
can subsequently blame on the compiler, because the user didn't do
anything. Not searching searching /usr/include is then based on the
pessimistic assumption that there can be a conflict and it's better
to have the user be explicit all the time so it's always his fault.
What applies to conflict also applies to headers not found.
If one likes:
s/optimistic/rose-colored/g
s/pessimistic/realistic/g
I don't see an inconsistency. Just differing point of views.
--
Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Terry Lambert
*nix forums Guru
Joined: 19 Mar 2002
Posts: 434
|
| Posted: Wed May 29, 2002 4:02 am Post subject:
Re: Why don't we search /usr/local/lib and /usr/local/include by default?
|
|
|
Greg 'groggy' Lehey wrote:
| Quote: | We shouldn't search /usr/local by default because PREFIX can be set
to anything.
It doesn't do any harm even in that case.
|
Actually, in this case, it can.
| Quote: | We shouldn't search it because that may break other things.
What?
|
The issue with "PREFIX" is that it's used for the "ports" system,
including "packages".
There _is_ actually a way that this could be bad. The place it
would be bad is for ports maintainers and ports users (but not
packages, since they will get caught during the build process).
The way this could go sour is to hide dependencies.
Consider a port maintainer who has a working system where they do
ports. This system may have things installed on it that the port
maintainer uses in everyday use of the system -- when the box is
not being used to maintain the port.
In this case, what this means is that an updated version of software
could grow a dependency on the installed software -- _because the
compiler finds it without being told_, ad the port maintainer may not
become aware of this situation at the time of the port _because the
compiler finds it_.
IMO, this is *probably* what happened with the recent "getopt_long"
problem that someone posted about to both -ports and -hackers.
FWIW, "PREFIX", in my book, is not a "ports-only thing". That makes
an argument against the extension your Linux friends want, based
soley on "PREFIX", pretty specious.
I'd also argue that ports should be maintained in a jail, so that
this is never an issue; we know already that we can have mistakes
in found dependencies, even if the linker and the autoconfig process
is too stupid gto catch them: that's why the packages build farm is
a farm, and why it requires "clean" system images to build out the
packages prior to a FreeBSD release. Without a "portsjail" port,
though, this is unlikely to magically happen all on its own.
FWIW, I think that the developement environment should cater to the
developer. You can argue this both ways: that it should be a minimal
set, or that it should "just work". I don't think it's correct to
try to make the "PREFIX" argument on the basis of ports maintainers,
though, since they aren't really the majority of developers.
On the other hand, it's pretty self-evident that the rules for doing
compiling (include paths) are different from those for linking (library
paths) are different from those from running (ldconfig cache contents),
and that these three things should at least *try* to be the same.
My own perspective, having used FreeBSD as a developement platorm for
code to be deployed on AIX and Solaris... is that FreeBSD "comes with"
too much crap. The OpenSSL stuff along means that any code I develope
without paying particular attention, is automatically unportable,
since I may forget to import the OpenSSL sources into my source tree,
incorrectly assuming that the OS will provide the support for me (this
is not true!). In general, I have to say that the FreeBSD ports
system itself doesn't take these dependencies into account very well
(I guess it would be the "Open Ports" system, if it did, since that
would mean it would run on any minimal POSIX compliant system, not
just FreeBSD).
It's very hard, IMO, to argue against including well known add-on
include and library paths in the compiler and linker, when they are
there in the ldconfig library path cache, and OpenSSL is in the base
system for FreeBSD, but not other OS's: the PREFIX argument is a
portability argument, and you can't make one portability argument
without making *all* portability arguments.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Thu Jan 08, 2009 6:18 am | All times are GMT
|
|
Loans | Payday Loans | Discount Magazines | Property in Abu Dhabi | Loan
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
BSD
»
FreeBSD
»
mail-lists
»
Architecture
