On 29/06/2016 8:43 AM, Alfred Perlstein wrote:
On 6/28/16 9:52 AM, Julian Elischer wrote:
At work I am doing various cross compiles in order to make a
product under freebsd that actually will run under a modified
FreeBSD that runs on an appliance. We want to get away from hand
rolling everything to leverage all teh work in getting ports
working well on FreeBSD.
We have some extra syscalls and some structures have different
sizes, so we need to compile/link agains an alternate set of
includes/libraries and not those in /usr/include or /usr/lib.
Ideally I want to use the "--sysroot" and "-isystem" options to the
compiler/linker or failing that, add a -I or -L entries to make it
look at the correct includes and libraries, not those in the base
system.
In many ports CFLAGS etc. are sent in via the arguments to
./configure or environment vars, but there are many other ports
that have other ways to specify these.
Does the ports framework have any standard way to do this?
LDEXTRA_ARGS or EXTRA_CFLAGS or similar?
I've looked around and can't really see anything. Best would be a
single file to which I could add these things but adding them to
the environment would also work.
yours in ports ignorance..
Sounds like a decent idea to override includedirs, but I wouldn't
trust it. :)
Why not do what NANOBSD/FreeNAS do and compile inside a chroot (or
even VM) with the proper includes and such installed?
we DO compile in a chroot. but that still requires that the local
binaries use one set of .so files and the generated ones use a
different set..
I do have ways around it.. like "rm -rf /usr/include/sys; ln -sfh
/usr/product/sys/sys /usr/include/sys"
It sounds like a big sledgehammer to use a chroot or a VM, but in
reality it's MUCH safer than some port accidentally pulling
something from the wrong /usr/include and then you spending hours,
days, etc tracking it down. Trust me, I've seen the fallout and
it's NOT FUN!!!
oh I have too.. tha't why I'm using a chroot, bur we dont' want to
generate a new chroot for every sub-point-release, and have to store
it away forever, so I'm making the chroots be "semi permanent" which
means that differences arize between them and the sources as we
diverge, and before we build another chroot..
For FreeNAS we made it so that you could run the FreeNAS OS (trueos)
as the actual build server and that saved us a huge number of
headaches.
yes I agree that would be nice but there are a large number of legacy
issues at play so a cross-build style work flow is what I can get to.
If you're very, very against the idea of VM or chroot then you could
just make /usr/include actually contain YOUR includes as you
probably shouldn't need them otherwise on a build server.
yeah I'm kind of doing that already.. IN the chroot.. wish I didn't
have to. the chroot system binaries are pretty much -RELEASE binaries.
but we use them to generare FOO-OS binaries which have to link to
other .so files.
-Alfred
-Alfred
_______________________________________________
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
