feature request for ports/fbsd

[extra_ceo]

it would be cool if ports supported compiling a port to a specific directory (ie ~/user or ~/fort) and allowed each binary to be statically compiled, not as an option to each port maybe, but maybe as a wrapper ie

cd /usr/ports/nntp/pan
fortsnap /home/extra-ceo/fort/ make -j

which should take the compiled data, copy it to the directory that was inputted, and POSSIBLY execute a script

it would work like this with fortsnap

1. compile the data with switches ($fortsnap0 = --prefix=$DIR --dont-know-static-switch)
2. copy the data from work/ to the directory that was inputted
3. possible execute a user included script (chmod, setting freebsd specific settings)


the reason is you can compile against many libraries and organize many huge binaries in many different directories, like a home dir, and statically linked binaries take all dependencies and compile them into a huge binary, and it allows for better organization in stuff like the home dir

 

[kpedersen]

I agree with the idea. I think the reliance on "hardcoded" paths (to libs as well as data) that so many UNIX applications have is such a wasted opportunity.

Close to your idea (ultimately relocatable binaries?), I put out a poll here. However it seems that many people aren't that bothered by the issue. Admittedly jails / chroots solve 99% of the problem.

However (for OpenBSD), I went ahead and implemented it anyway. It works well, I use it for pretty much everything large. Maybe you could adapt it for FreeBSD?

 

[SirDice]

and statically compiled binaries and a huge collection of easily archivable apps with your choice of libraries seems like the bees knees lol

Until there's a security issue in one of those libraries, then you're screwed and have to recompile everything. That's if you're aware that library was statically linked in one of those applications in the first place.

 

[kpedersen]

Until there's a security issue in one of those libraries, then you're screwed and have to recompile everything. That's if you're aware that library was statically linked in one of those applications in the first place.

I guess you only need to "relink" things. But admittedly most people probably clean their ports collection after a build.

In some ways though, if the (compromised) software was well encapsulated and not spammed in with the rest of the system, I personally would feel the update process to be cleaner and safer. Partially because it is more transparent (delete a directory, add a new one) and I wouldn't need to rely entirely on tooling.

 

[ralphbsz]

ty! ya, people really should utilize their free space to the fullest with modern hardware (if you have them) and statically compiled binaries ...

Why statically compiled binaries? Because they run faster? That's not always true. For a single program, it probably is true, as the library is loaded faster if included in the more compact single binary, compared to having to open more files. The moment you're running multiple programs that share the same library, you have space savings in memory, and a better chance of keeping library code in CPU cache, so dynamically linked binaries can easily run faster. Whether they do depends on your workload.

Try a before-and-after test to check the performance.