Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Building of native image fails if ant clobber` has been called #340

Open
sophie-kaleba opened this issue Jan 23, 2020 · 3 comments
Open
Labels
bug Fixes an issue, incorrect implementation

Comments

@sophie-kaleba
Copy link

Linux-only (I assume)

A call to ant native after an ant clobber makes the build fail with the following error:

native:
     [exec] Error: Invalid Path entry /home/sopi/Documents/Experiments/SOMns/libs/truffle/substratevm/mxbuild/linux-amd64/SVM_HOSTED_NATIVE/linux-amd64
     [exec] Caused by: java.nio.file.NoSuchFileException: /home/sopi/Documents/Experiments/SOMns/libs/truffle/substratevm/mxbuild/linux-amd64/SVM_HOSTED_NATIVE/linux-amd64
     [exec] 

BUILD FAILED
/home/sopi/Documents/Experiments/SOMns/build.xml:544: exec returned: 1

The directory SVM_HOSTED_NATIVE is indeed missing. It is usually generated by a call to mx build in the substratevm directory.

it comes from a change made on the dev branch (the clobber command actually cleans the truffle build, along with this directory) - I assume a call to mx build for the substratevm is missing somewhere, that or clobber is being overzealous.

@smarr
Copy link
Owner

smarr commented Jan 23, 2020

Hm, perhaps we miss a target that does that for svm.

Perhaps based on the one for truffle-libs: https://github.com/smarr/SOMns/blob/dev/build.xml#L158

@smarr smarr added the bug Fixes an issue, incorrect implementation label Jan 23, 2020
@sophie-kaleba
Copy link
Author

Actually, this line in the truffle-libs target <arg value="--no-native" unless:true="${build.native}" /> seems to prevent the build of the substratevm (see https://github.com/smarr/SOMns/blob/dev/build.xml#L164). Though I don't know why a first call to ant native does not raise the same issue.

Setting the value of build.native to true fixes the issue (ant -Dbuild.native=true native). But setting this value directly from the native target seems to be a pain because of the dependencies - I'll add a new target soon

@smarr
Copy link
Owner

smarr commented Jan 23, 2020

There's something very broken here. Strange that it works in the CI environment.

This build.native variable isn't actually set anymore.

We may want to wrap the target as it was previously.
See this commit: be827bc

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Fixes an issue, incorrect implementation
Projects
None yet
Development

No branches or pull requests

2 participants