Re: better way to build libraries..
- From: John-Mark Gurney <gurney_j@xxxxxxxxxxxxxxxxxx>
- Date: Fri, 29 Sep 2006 03:12:46 -0700
Ruslan Ermilov wrote this message on Fri, Sep 29, 2006 at 13:49 +0400:
On Fri, Sep 29, 2006 at 02:22:33AM -0700, John-Mark Gurney wrote:
are you saying thatYes, we've been doing this (removing them) for years now.
we should go ahead and remove all the -I../../sys in places like
pciconf because building standalone isn't supported?
pciconf is special -- it needs this because we don't install
sys/dev/pci/pcireg.h into /usr/include.
Interesting, other people seem to think that they are suppose to stay
around... I'll remeber to remove them when I see them from now on...
My point isRemoving -I's doesn't generally affect standalone building, but
that either we continue to attempt to support building things stand
alone, or we don't even pretend we attempt to...
it does affect stanalone upgrading. That's the difference. If
your sources match your installed bits, you can still chdir into
If my sources matched my installed bits, why'd I be building/upgrading
in the first place? :)
a directory and type "make", and it will generally be built.
Yes, we should stop pretending we support standalone upgrades --
because in this case you need to handle it properly: track
dependencies, build and install dependencies (other headers and
libraries, this library's headers if this is a library) in the
correct order, etc. Some of them depend on the src.conf (or
make.conf) options, there's a lot to track.
not if you know only that one library changed... and for most security
upgrades, it should be one or two components that are affected, and so
is simple enough to manage the dependencies...
Everyone points that oh, buildworld does that prefectly fine, but noI think you misunderstand the difference between upgrades and
one wants to expand support of being able to build FreeBSD piecemeal
on a system....
I understand the difference, I just think that standalone means not
requiring /usr/include to be populated w/ files from the component you
I wonder how many people's build and commit errors would have been fixed
by using a method like this... It built for me./Darn, I forgot to make
includes so I wasn't building w/ the proper headers.
Though I agree buildworld is good for testing, people don't have
infinately fast disks and cpu's, and buildworld takes time. I would
be very surprised if even 50% of commits are done w/ a proper buildworld
let alone a universe before committing...
It should work exactly how you build OpenSSL and other libraries that
aren't part of FreeBSD... you build them and they automagicly use the
includes that come w/ the package, and you install them all at once...
Yes, they usually depend upon other headers that are part of the
system, but as you said, dependencies are hard... If you're doing it
by hand, you can track the dependencies by hand..
Take my 5.4-R box... I was unable to build libcrypto due to notThis approach is doomed. You were lucky (or not, haven't actually
having done a make includes... I could do a make includes, but then
if either a) I forget to make and install the library, or b) the
library fails to build, I now have a broken install... It is
much better to do a build the library, then install both the new
library and includes...
checked) that this particular upgrade didn't update .h files.
not.. it modified a few of the .h files... I wouldn't have known
of this issue if it had left the .h files alone..
Because if it did, you'd still be forced to rebuild other bits that
use an updated header -- other crypto libraries, other stuff
that uses crypto, statically linked programs if there are any.
If we did update the .h file, and it did break the API, doesn't that
mean we need to have bumped the major number??
Well, if you absolutely want to, you could installed the headers
into a temporary location using DESTDIR,
make includes DESTDIR=/foo
then rebuilt the library with DEBUG_FLAGS=-I/foo. In any case,
even this broken approach doesn't require modifications to
Which is exactly what my patch did... though your method requires
root, which it shouldn't... (IMO this way is not broken, the the proper
way to build a library)...
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
freebsd-current@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"
- Prev by Date: Re: isofs/cd9660 -> relocate to fs/isofs/cd9660?
- Next by Date: Re: better way to build libraries..
- Previous by thread: Re: better way to build libraries..
- Next by thread: Re: better way to build libraries..