Does anyone here have experience with that? Because if I can reduce
my build machines to just one or two machines for Linux, I'd rather
We use rpath in the Easy Install script for Citadel.
All of the libraries that we compile are installed in a dedicated support directory, and we build our binaries with the rpath option to force them to prefer their own libraries over anything else that might already be installed on the system. It probably wouldn't be too difficult to take it a step further, include almost *all* libraries instead of just the specialty ones, and ship binaries.
At some point, though, you have to start wondering whether it would just be easier to static link everything.
Static linking has problems, too.
One big problem involves working with ODBC, which I need to do for one application.
In Linux, you must dynamically link your binaries for ODBC support, since the point of it involves a 3rd party vendor providing a shared object that provides the driver for the database in terms of ODBC.
Plus, you find yourself having to build for several distributions of Linux when you statically link, to ensure that the binaries work with the target kernel.
Plus, you find yourself having to build for several distributions of
Linux when you statically link, to ensure that the binaries work with
the target kernel.
If the glibc you're linking against is sufficiently old, you ought to be able to compile once and run on any subsequent compatible kernel.
Of course it does depend on whether you're using any of the more poorly-isolated shared libraries as a dependency
I plan to build the compiler on the target machine, just so I have a consistent language to use (GNU C/C++ 5.4.0). I can copy its libs into the rpathed folder.
But, then there's glibc, which isn't compiled with the compiler. And pthreads?
I have other libraries that I plan to compile anyway, just to ensure that we're working with something consistent (for example, openssl), so I'm hoping to contain some of the scariness to just a few things.
Microsoft announced on Monday a new technology called Azure Sphere, a new system for securing the tiny processors that power smart appliances, connected toys, and other gadgets.
...here's the really notable part: To power Azure Sphere, Microsoft has developed its own, custom version of Linux — the free, open source operating system that Microsoft once considered the single biggest threat to the supremacy of its Windows software.
(To bypass the ad blocker blocker on Business Insider, hit Ctrl-A Ctrl-C quickly before the modal comes up, then paste the article into a word processor to read it.)
So let me get this straight. There's supposedly a security problem caused by all of the "IoT" connected devices, toys, etc. out there, and the solution is to connect them all to Azure and give Microsoft control of them all?
I mean, yeah, kudos to Micro$oft for being non-NIH enough to realize that 'doze is to bloated for this application and going with a Linux kernel, but still ... tethering all IoT devices to Azure "for security purposes" sounds like a cure that's worse than the disease.
We have a few chuckles about the idea at work, too.
It's a ridiculously bold statement. I don't know how they can credibly back it.
It maintains a pinned-up connection to the mothership and it is bolted to the user's skull so that it cannot be removed.