The build uses -nostdlib which prevents GCC from auto-linking libgcc_eh.a. This library provides the SEH unwind symbols (_Unwind_Resume, __emutls_get_address, etc.) needed by C++ exception handling. Without it, any C++ target compiled with -fexceptions fails to link with undefined references to these symbols.
Add a libgcc_eh INTERFACE target that conditionally pulls in libgcc_eh.a when the toolchain provides it (as on SEH-enabled x86_64), falling back to a no-op otherwise (SJLJ/DWARF toolchains).
CORE-15156, CORE-19691, CORE-19692
Finally get rid of the livecd_start.cmd hack introduced waaaay back
in commit ff6d7b0236 (r54514)!
See also commits ea682b6909 (r54512) and 71867403fd (r54513).
For target paths, use the shell "special shell folder" syntax:
`shell:windows\...` or `shell:system\...`, introduced in commit
7b081be46d (PR #7158) by Whindmar Saksit.
Specify an explicit icon path and index for the "Read Me.lnk" shortcut.
Includes ideas from PR #7154 by Katayama Hirofumi MZ.
The generated shell links are confirmed to work on ReactOS, but also on
Windows 2003 and Windows 7.
- Change the MKSHELLLINK icon parameter syntax to be: `-i [icon_path[,nr]]`
where, either both `icon_path` and icon index are given, separated by
a comma ',' , or, either the `icon_path` is given but the index is
optional (default: 0), or, only the icon index is given, in which case
the icon path is set to the target instead.
- Use a `VERBATIM` command-line for `add_custom_command()`, so that *nix
builds can cope with parameters containing backslashes.
- The shortcut target path, working directory, command-line arguments,
and icon path all may specify explicit Win32 environment variables
(like `%SystemRoot%`, `%HOMEDRIVE%`, etc.). Because these environment
variables are specified as data given to the build tool via CMake,
**AND** we have to workaround keeping these variables unexpanded when
they are transmitted to the tool via CMD.EXE (on builds made on Windows),
specify these variables in an "escaped" format, using `^%` instead:
`^%SystemRoot^%`, etc.
Additionally these paths may be explicitly quoted and passed that way
to the MKSHELLLINK tool.
In order to deal with both unquoting the strings and unescaping the
environment variables, introduce a helper function and invoke them on
the aforementioned strings.
CMakeLists.txt: `add_livecd_shortcut()`:
Turn the macro into a function. Instead of keeping a `LIVECD_SHORTCUTS`
global-scope list variable, just define a `livecd_links` custom target
as initially empty, then, using `set_property()`, directly append to it
its "SOURCES" i.e. generated .lnk files.
(This is equivalent to using `target_sources(livecd_links PRIVATE ...)`
only in CMake 3.20+ for the custom target.)
CMakeMacros.cmake: `add_link()`:
- Since both `name` and `path` parameters are mandatory, make them
explicit in the function declaration instead of defining them as
"optional" parameters.
- Remove the `set_source_files_properties(... PROPERTIES GENERATED TRUE)`
invocation that followed the `add_custom_command(...)` call, since,
per the documentation[^1],
"Each output file will be marked with the `GENERATED` source file
property automatically." (Since CMake 3.2 at least.)
[^1]: https://cmake.org/cmake/help/v3.17/command/add_custom_command.html
CORE-9069, CORE-13525, RELEASE-11
This new BootCD contains the functionality of both the original bootcd
(text-mode 1st-stage installer) and the livecd (that will include the
1st-stage GUI installer later).
Our separate livecd ISOs become obsolete, and this completely removes
the need for the so-called "hybridcd" ISO.
Some details:
- The "hybridcd" build target is completely removed, since now the new
BootCD *is* basically what we used to call "hybridcd".
- The "livecd" build target is kept so far (to minimize the code changes),
but internally I start to refer to it as "LiveImage", and is reduced
to a minimum.
A minimal non-bootable "liveimg.iso" is built (but currently not
included within the BootCD). Its purpose will be to implement the
"ReactOS Live" functionality as a RAMDISK.
(We currently don't support other file formats apart from ISO and
flat disk for a RAMDISK).
The "ReactOS Live" (non-RAMDISK) is implemented by adding to the
BootCD file tree the files from the LiveImage.
These files add two root directories, "Profiles" and "reactos"
(which is the SystemRoot for the non-ramdisk LiveImage).
- The minimal text-mode ReactOS installation used for the 1st-stage
installer, including USETUP itself, and the executable for the
1st-stage GUI installer and the reactos.cab (installation source),
are moved to the root directory called "i386" (ideally, one directory
per architecture).
- The "bootcdregtest" target, i.e. the ISOs we feed our testbots with,
are left untouched, i.e. they are only constituted of the 1st-stage
text-mode installation only, but placed in a per-architecture root
directory ("i386", etc. as for the bootcd).
- Remove the ACPI APIC/SMP entries from bootcd.ini. They will be made
available via the Advanced Boot Options F8 menu in Debug builds, for
testing purposes only, in a subsequent commit.
This commit is based upon an older SVN one:
svn path=/branches/setup_improvements/; revision=75273
But add KDGDB compilation only for x86 and x64, since for other
architectures (e.g. ARM) it currently emits the following error:
```
drivers/base/kdgdb/kdgdb.h(149): fatal error C1189: #error:
"Please define relevant macros for your architecture"
```
For the time being, keep the "GDB" build configuration macro, used for
Gitpod testing... but this needs to be replaced with a more robust solution.
Because of this, rename kdgdb.dll to kdcom.dll, and kdcom.dll to kdser.dll
so that GDB is used by default, and we don't get a file name clash too.
Revert also commit 57cf5cdc5d.
Make the GNU linker behave less backwards and more like a real linker (like the MSVC one) by wrapping all libraries in a linker group, which essentially disables the linear ordering requirement for dependencies.
No more GCC linker dependency hell!
The sad thing is, that one has to resort to hacking the CMake linker command line to achieve this, as there is neither a global linker option nor a CMake option to achieve this.
This commit also modifies the linker command order slightly for consistency.
[SDK][WDFLDR] Add kmdf loader driver
[SDK][WDF] Add kmdf drver init static library
[SDK][WDF] Modify kmdf driver for working with wdfldr driver
[SDK][CDROM] Cdrom driver dynamically linking with kmdf
[SDK][WDF] Add kmdfdriver module type
[SDK][WDF][USBDEX][NTOSKRNL_VISTA] Fully enable KMDF
[KMDF][WDFLDR][WDF01000] Fix Windows 10 Compatibility WDFLDR and WDF01000
[WDF01000] NO_KERNEL_LIST_ENTRY_CHECKS for wdf01000 3rd party code
This PR is an accumulation of three peoples work, with the goal of the trying to get WDF to work like it should.
This has been tested in combination with some extra NT6+ ntoskrnl against multiple drivers.
---------
Co-authored-by: Max Korostil <[email protected]>
Co-authored-by: Victor Perevertkin <[email protected]>
Co-authored-by: Adam Słaboń <[email protected]>
Co-authored-by: Hermès BÉLUSCA - MAÏTO <[email protected]>
- Move sdk\include\reactos\wine to sdk\include\wine
- Reorder the directories in include_directories() to be closer to alphabetical. This should make it easier to determine what global include directories can be removed in the future.
"Far East Asian" Visual Studio had
generated a lot of "warning C4819:
File contains characters that
cannot be displayed in the current
code page...".
JIRA issue: N/A
Since VS 17.14.36203.30 / MSVC 19.44.35209.0 the default behavior on ARM64 is to not inline _Interlocked* functions. Until we have those implemented, we disable this feature, going back to the old behavior.
For additional details / tracking of the implementation see CORE-20255
It was introduced in commit 1f9c4940d (r38270), but this flag isn't used
anymore in our source tree, and nowadays, we actively compile both UP
and MP support.
Re-trial of #7800. Deleting __WINESRC__
hacks.
JIRA issue: CORE-5743
- Add sdk/cmake/set_wine_module.cmake.
- Load set_wine_module.cmake at
top-level CMakeLists.txt.
- Use set_wine_module cmake function
and delete __WINESRC__ as possible.
- Delete many include_directories.
It's purpose was to create x64 unwind information from DWARF debug info, but it was never fully working and is pointless now anyway, because x64 GCC does this itself properly.
This setting can be overwritten by defining the CMake variable HOST_BUILD_TYPE.
The target build type is passed to the host build as TARGET_BUILD_TYPE CMake variable.
This improves time to build cab+iso:
MSVC x86: 37s -> 28s
GCC x86: 32s -> 16s
__throw_out_of_range_fmt is implemented in libstdc++, but it is needed by libsupc++ and that would mean we would have to link all C++ code to libstdc++.
Do the same in add_idl_reg_script() (currently unused helper) as well.
This is an addendum to commit b587e7b32, where the removal of the
IDL_FILE_FULL variable definition, broke dependency tracking with
the DEPENDS option. Now we use the correct variable.
The problem was caught after doing a partial (non-clean) build after
commit 0d10fb814. In this commit, two new interfaces, IExecuteCommand
and IObjectWithSelection, were added in the psdk/shobjidl.idl file
and used elsewhere. Recompilation correctly regenerated the corresponding
header, psdk/shobjidl.h, but did not trigger a regeneration of the uuid
static library (via the regeneration of sdk/lib/uuid/shobjidl_i.c),
due to broken dependency tracking on the shobjidl.idl file.
Because of this, the shobjidl_i.c did not contain the new GUID
definitions for these new interfaces, IID_IExecuteCommand and
IID_IObjectWithSelection, and triggered linking errors for the
com_apitest, actxprxy and shell32 modules:
```
error LNK2001: unresolved external symbol _IID_IExecuteCommand
error LNK2001: unresolved external symbol _IID_IObjectWithSelection
fatal error LNK1120: 2 unresolved externals
```
* [UDFS] Clang: Fix a #pragma
'warning: unknown warning group '-Wstringop-overflow', ignored [-Wunknown-warning-option]'
Follow-up to 612b1f2e6 (0.4.15-dev-1129).
* [CREATESPEC] Clang: Fix a target_compile_options()
'warning: unknown warning option '-Wno-stringop-overflow'; did you mean '-Wno-shift-overflow'? [-Wunknown-warning-option]'
Addendum to 00ed72d7e (0.4.15-dev-1169).
* [MSVCRT_WINETEST] Clang*: Fix a target_compile_options()
'warning: unknown warning option '-Wno-stringop-truncation'; did you mean '-Wno-string-concatenation'? [-Wunknown-warning-option]'
Addendum to commits 00ed72d7e (0.4.15-dev-1169) then f155b9377 (0.4.15-dev-4612).
* [TELNET] Clang*: Fix a target_compile_options()
'warning: unknown warning option '-Wno-restrict' [-Wunknown-warning-option]'
Addendum to 447ef2aa4 (0.4.15-dev-4613).
Ahmed Arif