-] I installed Oracle Java SDK : /usr/ports/java/linux-oracle-jdk18
But the corresponding javac has been put into: /usr/local/linux-oracle-jdk1.8.0/bin/javac .
I don't understand, since this is Linux software it should be put under /compa/linux/xxxx, shouldn't it ?

Software from ports is almost always installed under /usr/local, including Linux applications. For example, the Linux versions of Opera, FlashPlayer and various games are installed under /usr/local, too. /compat/linux is only used for the linux base system.

--- this is wrong, corrected in next post ---------------------------------
-] I am still a quite perplexed, yesterday i red the relevant chapter of "Absolute FreeBSD 3rd ed." to
have an idea of how the Linux mode is working and there are relevant discrepancies.
For example this:

Well-Known Member

Let's consider what is written in the Handbook, chapter 10.3 and let's let aside "Absolute FreeBSD" which
you may not have at hand.

----- [a] ------------------------------------Linux® mode dynamically reroots lookups. This is, in effect, equivalent to the union option to file system mounts. First, an attempt is made to lookup the file in /compat/linux/original-path. If that fails, the lookup is done in /original-path. This makes sure that binaries that require other binaries can run. For example, the Linux® toolchain can all run under Linux® ABI support. It also means that the Linux® binaries can load and execute FreeBSD binaries, if there are no corresponding Linux® binaries present, and that a uname(1) command can be placed in the /compat/linux directory tree to ensure that the Linux® binaries cannot tell they are not running on Linux®.
-------------------------------------------

According to [a] , in my humble opinion,

1) It would be better that Linux binary would be installed under /compat/linux. Ineed, this way we could have "javac" for Linux (the Oracle one) and "javac" of OpenJDK for FreeBSD, they would coexist easily.... the same holds for other software. E.g. we could have "adb" of FreeBSD and "adb" of Linux etc. etc. etc.

2) In my previoud post example i made a mistake, I used the file command, which is not available under /compat/linux, so the FreeBSD file was used and this messed things up. Lets use od which is available in /compat/linux. We can see "linux bash" correctly looks for "linux binaries" first.

3) The mistery of why some binaries in /compat/linux are marked with ABI 00 instead of ABI 03
remains. According to this wikipedia page this should not be the case. And the handbookt, same
chapter as before, states that:
---------
For Linux® binaries to function, they must be branded as type Linux using brandelf(1):
---------

Ok, so the official brand number for Linux seems to be different, but the Linux binaries are still branded with ID 0. I don't know why, to be honest. Maybe the Centos people (from whom FreeBSD's Linux base is derived) just don't care because Linux doesn't use ABI emulation, so the brand ID doesn't matter there anyway.

By the way, only dynamically linked binaries have ID 0. The statically linked ones have ID 3. This probably has to do with the fact that dynamically linked Linux binaries use ld-linux-x86-64.so as the run time linker, which in turn is branded with ID 3.
Anyway, you usually don't have to care about branding at all. Normally it just works.

1) It would be better that Linux binary would be installed under /compat/linux. Ineed, this way we could have "javac" for Linux (the Oracle one) and "javac" of OpenJDK for FreeBSD, they would coexist easily....

Well-Known Member

Ok, so the official brand number for Linux seems to be different, but the Linux binaries are still branded with ID 0. I don't know why, to be honest. Maybe the Centos people (from whom FreeBSD's Linux base is derived) just don't care because Linux doesn't use ABI emulation, so the brand ID doesn't matter there anyway.

True, but I guess when stuff enter FreeBSD it should meet our higher standards of complience with the documentation. It would not be difficult to rebrand all ELF when e.g. "linux_base-c7-7.4.1708_6" gets installed. I may propose that in Bugzilla. I think it is a good thing to do.

By the way, only dynamically linked binaries have ID 0. The statically linked ones have ID 3. This probably has to do with the fact that dynamically linked Linux binaries use ld-linux-x86-64.so as the run time linker, which in turn is branded with ID 3.

On this I disagree. Even if things work they must respect the documentation. Or people (as me in this case) would read doc, shoot some commands and find things do not match => think the stuff is broken / code abandoned.

Well … If documentation and code differ, it is usually the documentation that is not up to date (or not precise enough), but the code is alright.
There are also cases where the documentation (e.g. the Handbook) simplifies things intentionally. Normally this is ok, because most people don't care. Only sometimes, people like you try to dig deeper.