Relocatable Compiler - 4.13 version #52
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dra27
force-pushed
the
relocatable-4.13
branch
2 times, most recently
from
48fc11e
to
4d7963f
Compare
When shebang scripts are available, camlheader_ur is simply `#!`, otherwise it is a copy of the executable header (camlheader). The linker checks that the shebang is not longer than 127 characters as per POSIX, but this assumed that it was a shebang being generated. If camlheader_ur was executable, the RNTM section was effectively corrupt. `SHEBANGSCRIPTS` is now recorded as `Config.use_shebang` and camlheader_ur is no longer generated.
Symtable.init didn't quote the runtime when executing it to get the primitive table meaning spaces and special characters were not supported. The linker for -use-runtime double-quoted the runtime value which meant further shell variables and so forth could be expanded. Filename.quote is now used instead.
When shared libraries are disabled, .cma files with stubs set a flag to force -custom mode. -use-prims and -use-runtime conflict -custom, but the error message was very confusing (since the linker attempts to load a shared object which cannot have been built). Alter the linker to detect this case and display a specific error message.
Removes dependency on boot/camlheader and stdlib/camlheader. -use-prims must be used with every invocation in order to ensure that a preinstalled binary in $(BINDIR)/bin/ is never called.
No need for two sets of headers now that the compiler doesn't use its set.
This option was present in configure since 4.08.0, but not actually implemented.
Newer glibc headers add __attribute__((warn_unused_result)) to write. Switch to fputs instead for the error messages in the header program.
When building OCaml for a prefix where the path to ocamlrun would exceed 125 characters, the previous fix in 4.10.0 ensured that the bytecode executables installed by the build would have valid shebang headers and also ensured that -use-runtime generated correct shebang headers, however camlheader* files which were installed contained an invalid shebang and so standalone bytecode executables emitted by the compiler would still have invalid shebang lines. camlheader files are now always executables. Systems using shebang headers no longer have camlheader* files. Bytelink.link_bytecode now handles the generation of all shebang lines (and consequently the use of exec if required).
Duplicates a buffer, converting the result to char_os (i.e. caml_stat_strdup_to_os but allowing embedded NULLs).
The first ld.conf found from $OCAMLLIB, $CAMLLIB or the preconfigured standard library location is loaded. Now all of these are loaded.
The runtime no longer needs the effective value, so remove the function and don't display it in ocamlrun -config.
Explicit relative paths in ld.conf are now interpreted relative to the directory containing ld.conf.
WIP because the error codes stuff in win32.c should be merged with win32unix
Change in error behaviour to test and document in Changes: Unix.rmdir "." should return EINVAL (but Windows returns EACCES - what's the actual error code?!). Unix.rmdir (Sys.getcwd()) presently returns EACCES but should now return EBUSY.
Custom runtime bytecode executables do not have a DLLS section: trigger the search for ld.conf only if there are dlls which need to be loaded.
Computes the relative directory from --bindir to --libdir.
This will be updated when sak is merged when it becomes a refactor to share the code in sak for doing this. It needs to remain in C since we need to convert the value on the OCaml side back to UCS-2 on Windows.
When linking an executable, allows extra global string values to be specified. In particular, this provides the ability to override caml_standard_library_default.
In native mode, even if a C object is being emitted, caml_standard_library_default should always be overridden (just as it is in -custom mode and -output-complete-executable mode in bytecode). The aim is to produce an object which can then be linked with both the native runtime and other C code - so caml_standard_library_default in the native runtime still needs to be overridden. A startup object has been produced, so the override still needs to take place.
Some dithering over whether this always needed to be written to native executables which led to an incorrect attempt to only override it in native mode if natdynlink or caml_sys_get_stdlib_dirs were used. However, this is incorrect: the native runtime is always linked, which if the relative stdlib has been cloned will be fundamentally the wrong value. Even if caml_standard_library_default is not used (via Config) then the incorrect value is still embedded in the resulting executable, so it makes sense that it is _always_ overridden. This code is therefore disabled in Asmlink with an "|| true" - the commit can eventually be parked in ocaml-experiments.
Appends the bytecode runtime ID to the name of the DLL, allowing CAML_LD_LIBRARY_PATH to point to the "wrong" stublibs directory.
This belongs mixed in with earlier commits...
Assuming nothing breaks, it's not clear why that could possibly be useful?
Not sure what the final fix should be - a possibility would be that -use-prims and -use-runtime are OK if they agree? Or maybe it is fine that we have to know that caml-tex will use -custom (it's our build system, after all...)
Mostly wchar_t related
wchar_t isn't available unless wchar.h has been included. The WIP is that these files contain strange embedding - the C++ part is fine, but the files aren't intended to be generic C files, so the use of #ifdef everywhere looks suspicious.
The global strings need to be treated as of type char_os - add a new primitive to expose caml_stat_strdup_to_os to OCaml code.
Not best way - could also force HAS_REALPATH in configure? Or remove the differentiation entirely - on a system without realpath then it just always behaves as if resolution failed.
Breaks on mingw-w64 ... need to double-check that it should be the case on _all_ platforms that the attribute must be used in both. In mingw-w64, IIUC it works because the weak symbols are renamed so that a strong symbol "just works".
Moving CAMLweakdef into configure broken mingw-w64 - this can probably just be left well-alone, or explicitly disabled for mingw? It appeared to be that the attribute needed to be on the declaration as well as the definition (perhaps this should always be the case - if there is a declaration in in the object, then it must also be weak?). The CAMLweakglobal/CAMLweakglobal should turn out to be unnecessary: this was needed early on when caml_standard_library_default was still in sys.o, but standard linking semantics can be used with it stored in stdlib.o instead - i.e. the "weak" (or default) symbol is in stdlib.o inside the .a and if its overridden, then it's always by an object on the commandline. In other wise, the problem was solved by moving the symbol to its own object file.
Provides a formal method for not including a bytecode executable and, more importantly, allows the boot compiler to select between a shebang or executable header, regardless of how the boot compiler was configured.
Symlinking was eval'd first, which was fine on Unix (ln with a temporarily dangling symlink) but not on Windows where it was a cp.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.