I can't find ffi lib when I test it on github action. The specific log is as follows
cp lib/libscale_ffi.so scale.go/libscale_ffi.so && cd scale.go && go test -v ./...
/tmp/go-build224195177/b001/scale-codec-comparator.test: error while loading shared libraries: libscale_ffi.so: cannot open shared object file: No such file or directory
FAIL github.com/gmajor-encrypt/scale-codec-comparator 0.001s
FAIL
https://github.com/gmajor-encrypt/scale-codec-comparator/runs/8134455052?check_suite_focus=true
github action code
https://github.com/gmajor-encrypt/scale-codec-comparator/blob/main/.github/workflows/scale-go.yml
Related
Is there a way to set different target names for development and release configurations using Cargo for building? For example, rustlibd.a and rustlib.a?
No. Debug vs release information is controlled by a profile. You can see all the profile-related manifest keys in the source code. The only related one I see is rustc_options. Running the build in verbose mode, you can see how cargo calls rustc:
$ cargo build --verbose
Compiling namez v0.1.0 (file:///private/tmp/namez)
Running `rustc --crate-name namez src/lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 -C metadata=5444c772a04e08f3 -C extra-filename=-5444c772a04e08f3 --out-dir /private/tmp/namez/target/debug/deps -L dependency=/private/tmp/namez/target/debug/deps`
Finished dev [unoptimized + debuginfo] target(s) in 0.45 secs
Unfortunately, changing --crate-name does not have the effect you'd like.
Instead, I'd point out that you already have a different filename, you just have to look broader:
target/debug/libname.a
target/release/libname.a
The debug and release files are in different directories. Whatever you were going to do to move separately named libraries would have to deal with the debug and release directories anyway. Just update your script:
mv target/debug/libname.a libnamed.a
mv target/release/libname.a libname.a
unfortunately I have paused the porting of a software of mine under OpenWRT due to a linking problem, but in order to go deeper into the above issue I need to briefly give you some details about my software.
It is made of three modules: LIB-1, LIB-2 and APP.
I'm developing it under LUbuntu with Netbeans/C++ and CMake. I'm cross compiling by CMake (I successfully followed this guide http://www.vtk.org/Wiki/CMake_Cross_Com … chain_file) and a I have built a toolchain and a target Generic-x86 OpenWRT image by the latest official BUILDROOT tool (it works under VirtualBox like a charm).
I set the CMAKE_LIBRARY_OUTPUT_DIRECTORY and CMAKE_RUNTIME_OUTPUT_DIRECTORY to a common folder (${CMAKE_BINARY_DIR}/bin) in order to have all the binaries into the same folder.
Now, I build the project for LUbuntu and inside the ouput folder I find LIB-1.so, LIB-2.so and APP, as expected. Then I execute 'ldd' on APP and I see it referencing LIB-1.so and LIB-2.so as expected. By the verbose CMake output I see also that CMake sets (as expected) the RPATH which points to '${CMAKE_BINARY_DIR}/bin'.
Now go into the issue details...
I build the project for OpenWRT and inside the output folder I find all the three files, as expected. Then I execute 'ldd' and 'objdump -x' and I see that APP links to '../bin/LIB-1.so' and '../bin/LIB-2.so' (file name plus a relative path prefix!!!). The other difference is that CMake (I don't know why) does not add the RPATH on the linking command line!
In order to get APP linked to the two libraries without the relative '../bin' path, I have to put the two SO files inside the APP linking folder, and manually run the linker stripping the '../bin/' prefix, and adding '-Wl,-rpath,${CMAKE_BINARY_DIR}/bin' too.
Could anybody explain me:
1) Why CMake links the two platforms using different command line parameters?
2) How can I link with CMake avoind embedding the relative .SO path?
3) If none of the readers uses CMake, could somebody tell me if exists an additional parameter for the G++ linker to strip relative paths from the referenced LIBs?
Thank you very much!
for the moment I found a workaround.
I create a bash script like this (openwrt-fix-libs):
#!/bin/bash
TARGET_NAME=$1
OUTPUT_DIR=$2
# Prologue
ECHO_PREFIX=[----]
echo "$ECHO_PREFIX Fixing OpenWRT library imports for \"$TARGET_NAME\"..."
# Dependencies copy
echo "$ECHO_PREFIX Copying libraries locally from \"$OUTPUT_DIR\"...";
cp $OUTPUT_DIR/*.so .
if [ $? != 0 ]; then
exit 1
fi
# Link command hacking
LINK_COMMAND=./CMakeFiles/$TARGET_NAME.dir/link.txt
echo "$ECHO_PREFIX Hacking link command at \"$LINK_COMMAND\"..."
LINK_COMMAND=$(cat $LINK_COMMAND | sed -e 's/\.\.\/bin\///g')
#echo "$ECHO_PREFIX <$LINK_COMMAND>"
if [ $? != 0 ]; then
exit 1
fi
# Re-linking
echo "$ECHO_PREFIX Re-linking...";
$LINK_COMMAND
if [ $? != 0 ]; then
exit 1
fi
# Update rebuilt binary
echo "$ECHO_PREFIX Updating \"$TARGET_NAME\" binary..."
cp *$TARGET_NAME* ${OUTPUT_DIR}
if [ $? != 0 ]; then
exit 1
fi
# Epilogue
echo "$ECHO_PREFIX Libraries imports successfully fixed."
Then I added into the CMakeLists.txt file of any module I need it this custom command:
if (_PLATFORM STREQUAL "OPENWRT")
add_custom_command(
TARGET ${_TARGET_NAME}
POST_BUILD COMMAND ${_GLOBAL_SCRIPTS_DIR}/openwrt-fix-libs ${_TARGET_NAME} ${_GLOBAL_OUTPUT_DIR}
)
endif (_PLATFORM STREQUAL "OPENWRT")
Where _PLATFORM is a symbol set by me on the command line when I compile for OpenWRT, _GLOBAL_SCRIPTS_DIR is my project scripts folder, and _GLOBAL_OUTPUT_DIR then bin inside the CMake building root.
I hope it maybe useful for you too.
I'm having some trouble building the csv library libcsv.
I'm using Windows XP, MinGW compiler and MSYS command shell.
It configures ok (./configure) but when I go to build it I get the below error. I realise it has to do with autoconf (it requires 2.65 or above) So what do I do here. Do I download autoconf and have it in a separate directory marked c:\autoconf and have an environmental variable pointing to it? Or,, does it go in the MSYS folder.
I have downloaded the binaries for autoconf and I just get a bunch of files. The binary files are in a SHARE folder and a 'bin' folder. Do I put their contents into the MsYS share and bin folders? Looking around the web I'm also seeing references to putting the autoconf binaries into my MinGW/bin folder. I'm really not sure what to do here?
Can anyone help? Thank you.
xxxx#XXXX-2FEF09FD39 ~
$ cd C:\libcsv-3.0.3
xxxx#XXXX-2FEF09FD39 /c/libcsv-3.0.3
$ make
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /c/libcsv-3.0.3/missing --run autoconf
/bin/m4: unrecognized option `--gnu'
Try `/bin/m4 --help' for more information.
autom4te: /bin/m4 failed with exit status: 1
make: *** [configure] Error 1
xxxx#XXXX-2FEF09FD39 /c/libcsv-3.0.3
$
i'm new at Travis CI and I want to ask you how to exactly use Travis CI to compile OpenGL with a lot .cpp, .h files. If you can hint me how to create correct .travis.yml file.
Also I tried to this but i'm getting this error:
The command "./configure && make" exited with 127.
/home/travis/build.sh: line 41: ./configure: No such file or directory
.travis.yml file:
language: cpp
compiler:
- gcc
- clang
Change this to your needs
script: ./configure && make
There must be a 'configure' file in the directory where the build starts. It is possible that you are using autotools, and need to run ./autogen.sh or autoreconf first, which generates the configure file. It is possible you are integrating travis with github, and your repository has a .gitignore that ignores the configure file (as it should) so that there is no configure file in the repository (only in your build directory on your dev machine.)
I am using gradle 1.4, and renamed a build.gradle to buildExpr.gradle and settings.gradle to settingExpr.gradle, both files are in the project root, and I am using following command to run gradle build.
'gradle C:\myProject>gradle -i -b buildExpr.gradle -c settingsExpr.gradle project'
it seems command line option '-c' is not being honored and gradle is not picking settingsExpr.gradle file, hence it is not able to display all modules defined in settings.gradle file while executing project task.
I am getting following log
-------------------------------------LOG----------------------------------------------------
C:\ASM\asm_workspace\asm71\AutoLab>gradle -i -c settingsExpr.gradle -b buildExpr.gradle project
Starting Build
Settings evaluated using empty settings script.
Projects loaded. Root project using build file 'C:\ASM\asm_workspace\asm71\AutoLab\buildExpr.gradle'.
Included projects: [root project 'AutoLab']
Evaluating root project 'AutoLab' using build file 'C:\ASM\asm_workspace\asm71\AutoLab\buildExpr.gradle'.
All projects evaluated.
Selected primary task 'projects'
Tasks to be executed: [task ':projects']
:projects
Root project
Root project 'AutoLab'
No sub-projects
it is very strange behavior by gradle command line shows. but if I change buildExpr.gradle to build.gradle and settingsExpr.gradle to settings.gradle, it executes normally and shows all sub-modules in log
-b and -c can't be used together. When using a settings file, everything else (e.g. the locations of build files) is determined from the settings file.