<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 09/24/2016 02:31 PM, Jeff Frontz
wrote:<br>
</div>
<blockquote
cite="mid:CAGvwsDmHe4NzF9S5hCQQP=RQTTKdKOSH82WggOQ0GCFOvwr2Hg@mail.gmail.com"
type="cite">
<pre wrap="">I googled "freebsd netbsd abi" and this was the top hit: NetBSD Binary
Emulation (<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.netbsd.org/docs/compat.html">http://www.netbsd.org/docs/compat.html</a> ). According to that
page (under <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.netbsd.org/docs/compat.html#ports">http://www.netbsd.org/docs/compat.html#ports</a> -- "Which OSs can
I emulate on my machine?") on i386 NetBSD you can run:
- BSDI (up to BSDI 3.x binaries)
- FreeBSD(x86) (a.out and ELF binaries)
- IBCS2 systems
- Interactive Unix
- SCO Unix
- SCO Xenix
- Linux(x86)
- Solaris(x86)</pre>
</blockquote>
<br>
Thanks! Fabulous! <br>
So what I'll do is add logic such that on NetBSD, if the '<font
face="Courier New, Courier, monospace">setup</font>' script is run
on NetBSD it will accept a FreeBSD or Linux or Solaris build and
hope for the best. (But if it finds NetBSD, it will use that, of
course.) The point being that I can defer building packages on
NetBSD, though I'll test that one of the others is usable there. <br>
<br>
Juicy articles deleted for brevity. <br>
<br>
I probably should have known that CYGWIN-built might not run in a
MinGW world because I know all too well that CYGWIN linkage by
default requires <font face="Courier New, Courier, monospace">cygwin1.dll</font>
to create the Unix-like environment. Pretty sure that some trick in
how the DLL is loaded results in the cross-process "stuff"
persisting, which would be more difficult with static linkage. I've
never dug into the details. <i>Maybe</i> MinGW-built can run on
CYGWIN (?), but if one of the things lost is sym-links then I'm kind
of outta luck. Lotso things require sym-links.
<br>
<br>
<br>
<blockquote
cite="mid:CAGvwsDmHe4NzF9S5hCQQP=RQTTKdKOSH82WggOQ0GCFOvwr2Hg@mail.gmail.com"
type="cite">
<pre wrap="">But, really, what is the problem you're trying to solve? ...
</pre>
</blockquote>
<br>
That is the $64000 question. Details at end. <br>
The short of it is to do <u>something like Mac OS X "Home Brew"</u>
but for any Unix or Unix-like environment. <br>
You can [re]build from source if you have to, but you might be able
to find and run a pre-compiled copy of whatever package you're
after. <br>
<br>
Let me re-phrase that: I'm already doing something sorta like Home
Brew and it is getting out of hand. <br>
The ABI question is an attempt to reign it in. <br>
<br>
<br>
<blockquote
cite="mid:CAGvwsDmHe4NzF9S5hCQQP=RQTTKdKOSH82WggOQ0GCFOvwr2Hg@mail.gmail.com"
type="cite">
<pre wrap=""> ... Do you want to
just build something or do you want to actually test it as well? For
build-only, you could set up cross-compilation/build environments that are
radically different from the hosted environment (GNU's SDK obviously
supports this -- that's how the virus spreads <span class="moz-smiley-s3" title=";-)"><span>;-)</span></span>. But to actually
test/certify that something runs in another environment (even just a
different version of the same environment), you really need to have that
target environment running (if only in a virtual machine).</pre>
</blockquote>
<br>
Testing is good. Testing is wise. "Test early. Test often." <br>
This conversation helps: I see a gap in my plan. I don't test all
the platforms where a build <i>might</i> work. For those, it's
usually manual "try it", and then re-do a specific build for that
platform. But this is both manual and late in the game. <br>
<br>
<br>
<blockquote
cite="mid:CAGvwsDmHe4NzF9S5hCQQP=RQTTKdKOSH82WggOQ0GCFOvwr2Hg@mail.gmail.com"
type="cite">
<pre wrap="">Maybe it's that you want the fewest number of packages?</pre>
</blockquote>
<br>
When building from source, for any single <i>package</i>, I want to
have as many <i>platforms</i> in the can as possible, without
falling into per-distro type complexity common with Linux. I have a
good handle on building for Linux w/o distro or runtime sensitivity,
but have been away from the others for too long (and the field is
bigger, the BSDs have grown up). <br>
<br>
----- cut here -----<br>
<br>
Previous work environments were heavy with NFS and automounter. We
could build some FOSS package and just toss it out there for any
Unix system to mount and run. It was/is easy to identify the package
(and release) and the available platforms. In the early days, I
sometimes found the need to identify the platform release (e.g.,
Solaris-5.1.1 versus Solaris-5.1.2) but that was rare. Platform
release never worked for Linux because the kernel and the runtime
library are independent (and runtime library was always a bigger
factor for the "will it run?" question). Over time, more operating
systems supported other hardware, OS X on PPC and now X86_64/AMD64,
Solaris on SPARC and *86*, Linux on <i>anything</i>. <br>
<br>
We don't use shared filesystems as much now (everything is file
synch instead), but we do sometimes use shared disks. (Think
removable media, but also SAN/iSCSI or shared virtual.) Then too,
containers are a new reason to again share filesystems (whether on
disk or networked or bind/alias/shadow). <br>
<br>
All of this is <u>outside of the usual package manglement</u>,
which would complicate handling packages outside of "vendor space"
(or maybe "distributor space") and is also tough for people to do
w/o admin privs. <br>
<br>
Example: <br>
At the PGP key signing, someone might come with a stash of CD or
flash media with GPG 4.1.20 pre-compiled for Linux and Windoze and
OS X. The way I'd do that is to have ... <br>
<br>
<ul>
<li>an ISO-9660 FS </li>
<li>with a directory called "<font face="Courier New, Courier,
monospace">gnupg-4.1.20</font>" </li>
<li>and sub-directories "<font face="Courier New, Courier,
monospace">Linux-i386</font>" and "<font face="Courier New,
Courier, monospace">CYGWIN-i386</font>" and "<font
face="Courier New, Courier, monospace">Darwin-i386</font>" </li>
</ul>
<br>
Maybe other HW too if time and resources allowed for them.
AMD64/X86_64 is a bi-modal architecture so "<font face="Courier New,
Courier, monospace">-i386</font>" runs there, but we could also
have "<font face="Courier New, Courier, monospace">-x86_64</font>"
directories to go along with these three example systems. It's all
"just make" under the covers. <br>
<br>
A CD with GPG is one of a bazillion point-and-run examples. Flash,
NFS, SMB, shared disk images, shared LUNs (SAN or iSCSI or whatever)
... or just pull pre-built stuff from a repo via TAR or RSYNC. So
we're back to file synch again, full circle. <br>
<br>
-- R; <><<br>
<br>
<br>
<br>
</body>
</html>