How to build with emcc in gradle using c plugin - gradle

I'm trying to compile project with emcc using gradle and so far failing to find any decent example of how it can be done (or to learn to to it on my own).
What I've tried to do so far is to set path to clang this way:
model {
toolChains {
clang(Clang) {
path "<path-to-emcc>"
}
}
...
}
I'm getting a "Could not find C compiler 'clang'." message.
Next thing I've tried is to create a clang symlink to emcc, but, again, failed miserably.

Were you able to find a solution for this?
I am having the same exact problem and, after looking around in the Gradle source code, this seems to be an issue specific to running the build on Windows:
ToolSearchPath.java:
private File findExecutable(OperatingSystem operatingSystem, String name) {
List<File> path = pathEntries.isEmpty() ? operatingSystem.getPath() : pathEntries;
String exeName = operatingSystem.getExecutableName(name);
try {
if (name.contains(File.separator)) {
return maybeResolveFile(operatingSystem, new File(name), new File(exeName));
}
for (File pathEntry : path) {
File resolved = maybeResolveFile(operatingSystem, new File(pathEntry, name), new File(pathEntry, exeName));
Because of the String exeName = operatingSystem.getExecutableName(name); line, Gradle is actually looking for emcc.exe instead of emcc.bat.
Update # 2020-07-14
I was able to get around above problem by making these changes.
But now I am stuck with following issue which is much harder to tackle:
> Task :linkDebug FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':linkDebug'.
> java.lang.NullPointerException (no error message)
After debugging Gradle's own code, I was able to determine that this issue is caused by emlink.py not handling special -dM -E -v arguments combination when Gradle's GccMetadataProvider probes it with these arguments in order to determine linker version.

Related

Access denied when building esp-idf-sys for Rust project for ESP32 on Windows 10

I'm attempting to set up this Rust template project to get started doing Rust development for ESP32: https://github.com/esp-rs/esp-idf-template
I've installed the Rustup esp toolchain, as described here: https://github.com/esp-rs/rust-build
At the Generate the Project step, I chose these parameters:
Configure project to use Dev Containers = false
ESP-IDF native build version = v4.4
Rust toolchain = esp
STD Support = true
MCU = esp32
At the Build step, I get this output (second run displayed, first run compiles a long list of dependencies before this point):
C:\Users\Me\boop\doop>cargo build
Compiling esp-idf-sys v0.31.6
error: failed to run custom build command for `esp-idf-sys v0.31.6`
Caused by:
process didn't exit successfully: `C:\Users\Me\boop\doop\target\debug\build\esp-idf-sys-cafd80a349bfdbb2\build-script-build` (exit code: 1)
--- stdout
cargo:rerun-if-env-changed=IDF_PATH
cargo:rerun-if-env-changed=ESP_IDF_TOOLS_INSTALL_DIR
cargo:rerun-if-env-changed=ESP_IDF_VERSION
cargo:rerun-if-env-changed=ESP_IDF_REPOSITORY
cargo:rerun-if-env-changed=ESP_IDF_SDKCONFIG_DEFAULTS
cargo:rerun-if-env-changed=ESP_IDF_SDKCONFIG
cargo:rerun-if-env-changed=MCU
IDF_PYTHON_ENV_PATH=C:\Users\Me\boop\doop\.embuild\espressif\python_env\idf4.4_py3.10_env
PATH=C:\Users\Me\boop\doop\.embuild\espressif\tools\esp32ulp-elf\2.28.51-esp-20191205\esp32ulp-elf-binutils\bin;C:\Users\Me\boop\doop\.embuild\espressif\tools\cmake\3.23.1\bin;C:\Users\Me\boop\doop\.embuild\espressif\tools\ninja\1.10.2\;C:\Users\Me\boop\doop\.embuild\espressif\python_env\idf4.4_py3.10_env\Scripts;C:\Users\Me\boop\doop\.embuild\espressif\esp-idf\release-v4.4\tools;%PATH%
Current system platform: win64
Skipping xtensa-esp32-elf#esp-2021r2-patch3-8.4.0 (already installed)
Skipping cmake#3.23.1 (already installed)
Skipping ninja#1.10.2 (already installed)
Skipping esp32ulp-elf#2.28.51-esp-20191205 (already installed)
IDF_PYTHON_ENV_PATH=C:\Users\Me\boop\doop\.embuild\espressif\python_env\idf4.4_py3.10_env
PATH=C:\Users\Me\boop\doop\.embuild\espressif\tools\esp32ulp-elf\2.28.51-esp-20191205\esp32ulp-elf-binutils\bin;C:\Users\Me\boop\doop\.embuild\espressif\tools\cmake\3.23.1\bin;C:\Users\Me\boop\doop\.embuild\espressif\tools\ninja\1.10.2\;C:\Users\Me\boop\doop\.embuild\espressif\python_env\idf4.4_py3.10_env\Scripts;C:\Users\Me\boop\doop\.embuild\espressif\esp-idf\release-v4.4\tools;%PATH%
--- stderr
Using managed esp-idf repository: EspIdfRemote { repo_url: None, git_ref: Branch("release/v4.4") }
fatal: No names found, cannot describe anything.
Using esp-idf v4.4.1 at 'C:\Users\Me\boop\doop\.embuild\espressif\esp-idf\release-v4.4'
fatal: No names found, cannot describe anything.
Error: Access is denied. (os error 5)
I get the same error when I choose ESP-IDF native build version = v4.3.2, although without the fatal: No names found, cannot describe anything. messages.
I get an identical error when attempting to build this Rust ESP32 demo project: https://github.com/ivmarkov/rust-esp32-std-demo
This was run as Administrator.
In my search for a solution, I found this: Why os.rename sometimes returns error access is denied python Per the top answer, I disabled "Show frequently used folders in Quick access" in File explorer, but unfortunately the build error has not changed.
What access is being denied, and what could be causing the denial, even when run as Administrator?
Secondarily, what is the cause and meaning of the fatal: No names found, cannot describe anything. messages?
I've been working through the same issue today.
It is caused by a change in the embuild dependency: https://github.com/esp-rs/embuild/commit/d8f8da228f1e1e6c105074d96617a8601092f633
Trying to write permission data to an open file causes the 'os error 5
I've submitted a PR to the project: https://github.com/esp-rs/embuild/pull/56
Now merged, cargo update and you should be good!

Why am I getting an Xcode build error from lex "gm4:stdin:1744: ERROR: end of file in string"

Building a github .xcodeproject and running into the same error for two forks of manOpen. I am having trouble understanding what the issue is.
I am new to building using Xcode so figure this must be simply a "new user mistake".
I cloned the project into /usr/local/Projects
When I build I get this error:
Lex /usr/local/Projects/ManOpen/ManOpen/cat2html.tproj/cat2html.l (in target 'cat2html (Tool)' from project 'ManOpen')
cd /usr/local/Projects/ManOpen
export DEVELOPER_DIR\=/Applications/Xcode.app/Contents/Developer
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lex -o /Users/john/Library/Developer/Xcode/DerivedData/ManOpen-bztxjqkaqtyazxhiudyipgfevout/Build/Intermediates.noindex/ManOpen.build/Debug/cat2html\ \(Tool\).build/DerivedSources/cat2html.yy.c /usr/local/Projects/ManOpen/ManOpen/cat2html.tproj/cat2html.l
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/gm4:stdin:1744: ERROR: end of file in string
Command Lex failed with a nonzero exit code
Not a fix, but a work-around: ManOpen Uses cat2rtf as of Mac OS 10.4, so you can remove cat2html as a dependency of ManOpen.

Please use compiler that supports __attribute__((constructor))

I just compiled my own version of gcc/9.2.0 using gcc/4.8.2. After successful compilation and installation of gcc/9.2.0 I try compiling ucx-1.5.1. When I try to run the ucx configure script I get the following message "checking attribute((constructor))... configure: error: Cannot continue. Please use compiler that supports attribute((constructor))".
When I run the script using the old gcc/4.8.2 I get no error at all.
Any idea what went wrong?
Any idea what went wrong?
No.
You can have a look at the respective config.log file, it usually contains additional information. In general, not every compilation error during configue indicates a problem, it's usually just feature test that just revealed a specific feature is not available.
Ucx uses next code to determine support of attribute __attribute__((constructor)). You can test it by yourself:
gcc -x c - <<EOF
static int rc = 1;
static void constructor_test() __attribute__((constructor));
static void constructor_test() { rc = 0; }
int main() { return rc; }
EOF
And post here if you have some errors.
I had the same problem, because I installed a software named "binutils-devel" on CentOS 8.4.
When "binutils-devel" was removed, the compile of ucx was successful.

DMD: misunderstandings with linking and building

I'm trying to build a project, using the DMD-compiler itself (without IDE) in Windows. And I found myself hardly capable to realise some moments about linking. Usually the IDE does this for me.
The structure of my project
project
├──bin
| ├──exemple.obj
| └──exemple.exe
└──src
├──a
| └──b.d
└──exemple.d
exemple.d
import a.b;
void main() { B obg = new B(); }
b.d
module a.b;
class B {
private int i;
public this() {i=0;}
public void act() {i++;}
}
At first it seemed to be easy to build with command:
cd C:\path\to\my\project
dmd bin\exemple.exe src\exemple.d -IC:\path\to\my\project\src
But it only showed me some error-massages:
OPTLINK (R) for Win32 Release 8.00.13
Copyright (C) Digital Mars 1989-2010 All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
bin\exemple.obj(exemple)
Error 42: Symbol Undefined _D1a1b1B7__ClassZ
bin\exemple.obj(exemple)
Error 42: Symbol Undefined _D1a1b1B6__ctorMFZC1a1b1B
--- errorlevel 2
Finally I guessed that the obj-file was missing. I made it manually with commands:
cd bin
dmd ..\src\a\b.d -c
cd ..
And manually added it to my build-command:
dmd bin\exemple.exe src\exemple.d -IC:\path\to\my\project\src bin\b.obj
And now it works.
Great. But what if we've got lots of additional d-files and complicated folders structure?
How could it be atomised?
I was strongly surprised, when I found out that DMD doesn't doing all this automatically. Maybe, I'm just doing it wrong.
You don't have to build a/b.d separately. But you do have to pass all source (or object) files to dmd. dmd does not figure out the dependencies.
Have a look at rdmd. It's a tool that does figure out the dependencies and then runs dmd on all of them (and then it runs the executable by default, --build-only prevents that). It comes with the dmd releases.

jdk 1.7.25 CORBA idl build warning: Anonymous sequences and array are deprecated

My java project updated to jdk 1.7.25, over Solaris 10 environment, this is the first time seen that there is a new warning message in build log: Anonymous sequences and array are deprecated (build IDL)
problem: The main GUI(build by jdk 1.7.25) cannot been brought up
We think this maybe a problem(but not sure). The idl file is very simple:
$ cat UnsubscribeAttb.idl
//../../../proj/request/requestIfc/UnsubscribeAttb.idl
include ../../../proj/request/requestIfc/subscribeKey.idl
module requestIfc {
struct requestIfc {
bool subscribeKeys;
sequence<subscribeKey> UnsubscribeAttbList;
}
}
I put in "typedef" at the front of the last line, but build immediately gives an error complained this line, but didnot give me a specific reason. Looking for your help.
Thanks,
Curtis

Resources