Closed csonsino closed 1 month ago
Hello!
The respack
and repository
tools like others are compile-time generated tools that process and generate built-in resources that are then linked with the binaries. AFAIR these tools are built a bit differently as it is reflected in the 'HOST_' prefix of variables used to store their names and arguments. They also use HOST_CXXFLAGS
instead of CXXFLAGS
variables etc. But at this moment the HOST_CXXFLAGS
is defaulted to CXXFLAGS
which is computed according to the ARCHTECTURE
setting.
I think you can help with cross-compilation if you dig into make files.
Things seem to go a bit better if I set HOST_
variables corresponding to my build machine, until the $(HOST_UTL_RESPACK) task.
$(HOST_UTL_RESPACK_OBJS)
references .o files under .build/host/...
, and $(HOST_UTL_RESPACK_LIBS)
references .o files under .build/target/...
, which happen to link okay when host and target are the same but not so well when they are different. Something seems a bit odd about the $(HOST_UTL_RESPACK_LIBS)
objects actually being under the .build/target
directory.
I've just updated source code and sub-projects and additionally optimized the build, so you need to pass CROSS_COMPILE=1
option to make config
if you want to cross-compile source code.
Please try to build plugins from the devel
branch now.
There is a host/target issue with the A/B Tester plugin, but if I disable that one plugin then it looks like I'm able to get a successful cross compile build. I'll have to do a bit more work to validate that the .so is usable on the target device, but this is great progress. Thanks so much!
After looking at this a bit more I don't think that the "modules/lsp-plugins-*" plugins are cross compiling (I'm seeing "error adding symbols: file in wrong format" when linking). Will see if I can figure it out.
I think that this is working for me (adding $(HOST)
in a few places):
<lsp-plugins>/modules/lsp-plugins-ab-tester$ git diff
diff --git a/src/Makefile b/src/Makefile
index 53214de..bc85e59 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -90,7 +90,7 @@ XOBJ_TEST = $(if $(OBJ_TEST),$(OBJ_TEST),$(OBJ_STUB))
CXX_FILE = $(patsubst $(ARTIFACT_BIN)/%.o,%.cpp, $(@))
DEP_FILE = $(patsubst %.o,%.d, $(@))
-CFLAGS_DEPS = $(foreach dep, $(call uniq, $(DEPENDENCIES)), $(if $($(dep)_CFLAGS), $($(dep)_CFLAGS)))
+CFLAGS_DEPS = $(foreach dep, $(call uniq, $(DEPENDENCIES)), $(if $($(HOST)$(dep)_CFLAGS), $($(HOST)$(dep)_CFLAGS)))
BUILD_ALL = $(ARTIFACT_LIB) $(ARTIFACT_SLIB) $(ARTIFACT_PC)
ifeq ($(TEST), 1)
@@ -114,14 +114,14 @@ $(CXX_SRC_STUB):
echo "#include <stdio.h>" > $(CXX_SRC_STUB)
$(OBJ_STUB): $(CXX_SRC_STUB)
- echo " $(CXX) [$(ARTIFACT_NAME)] $(CXX_FILE)"
+ echo " $($(HOST)CXX) [$(ARTIFACT_NAME)] $(CXX_FILE)"
mkdir -p $(dir $@)
- $(CXX) -o $(@) -c $(CXX_SRC_STUB) -fPIC $(CXXFLAGS) $(ARTIFACT_MFLAGS) $(EXT_FLAGS) $(INCLUDE) $(CFLAGS_DEPS) -MMD -MP -MF $(DEP_FILE) -MT $(@)
+ $($(HOST)CXX) -o $(@) -c $(CXX_SRC_STUB) -fPIC $($(HOST)CXXFLAGS) $(ARTIFACT_MFLAGS) $(EXT_FLAGS) $(INCLUDE) $(CFLAGS_DEPS) -MMD -MP -MF $(DEP_FILE) -MT $(@)
$(OBJ):
- echo " $(CXX) [$(ARTIFACT_NAME)] $(CXX_FILE)"
+ echo " $($(HOST)CXX) [$(ARTIFACT_NAME)] $(CXX_FILE)"
mkdir -p $(dir $@)
- $(CXX) -o $(@) -c $(CXX_FILE) -fPIC $(CXXFLAGS) $(ARTIFACT_MFLAGS) $(EXT_FLAGS) $(INCLUDE) $(CFLAGS_DEPS) -MMD -MP -MF $(DEP_FILE) -MT $(@)
+ $($(HOST)CXX) -o $(@) -c $(CXX_FILE) -fPIC $($(HOST)CXXFLAGS) $(ARTIFACT_MFLAGS) $(EXT_FLAGS) $(INCLUDE) $(CFLAGS_DEPS) -MMD -MP -MF $(DEP_FILE) -MT $(@)
# Linking targets
$(ARTIFACT_OBJ_META): $(XOBJ_MAIN_META)
I'm happy to do a PR if you really want, but this change has to be applied in each of the modules/lsp-plugins-<plugin>/src/Makefile
so that would be quite a lot of PRs...
Don't do PR for all plugins. I'll add this patch to lsp-plugins-plugin-template
and propagate it to all plugins.
I'm trying to resolve one problem with lsp-plugins-crossover
during metadata validation, but not sure if this is caused by the above patch. As far as I can tell the rest of the plugins work with that patch:
g++ -march=x86-64 -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security [lsp-plugin-fw] validator
Validating plugin metadata
Port id='scl' clashes another port id='scl' for plugin uid='compressor_mono'
Port id='scl_l' clashes another port id='scl_l' for plugin uid='compressor_lr'
Port id='scl_r' clashes another port id='scl_r' for plugin uid='compressor_lr'
Port id='scl' clashes another port id='scl' for plugin uid='sc_compressor_mono'
Port id='scl_l' clashes another port id='scl_l' for plugin uid='sc_compressor_lr'
Port id='scl_r' clashes another port id='scl_r' for plugin uid='sc_compressor_lr'
Overall validation statistics: plugins=182, warnings=0, errors=6
make[3]: *** [Makefile:1332: validate] Error 38
I've propagated all changes to all plugins, you can try to update source tree.
With compressor: it seems to be a regression that I missed yesterday when adding new functions: https://github.com/lsp-plugins/lsp-plugins-compressor/actions/runs/10909278249/job/30277129316#step:8:3751
Just committed changes that fix the problem for compressor.
Latest devel
changes look good to me. All plugins are cross compiling and the (lv2) library & manifest are usable on my target platform. Flanger is flanging :)
Can you give any instructions of how to cross-compile the package of plugins or add some instructions here?
Done (https://github.com/lsp-plugins/lsp-plugins/pull/441) Feel free to modify the text in any way you like.
Available in lsp-plugins 1.2.18. Thanks!
Is cross compiling this project expected to work? (v1.0.25 / master 447b8e1bc802107f7877620980008eb7bd5e299c)
I'm trying to cross compile
lsp-plugins
(v1.2.17) for aarch64 on an x86-64 machine, but it's failing with this error:I'm trying to start simple and build only the
lv2
plugins for now, specifically without the UI dependencies, so I'm using thismake config
:The
/lib/ld-linux-aarch64.so.1
library that it cannot seem to find does exist in my sysroot directory, but I don't really understand what's going on with respect torespack
andrepository
. It seems like those are binaries that are being cross compiled to aarch64, but then invoked during the build in the x86-64 context? If that's the case then I wouldn't expect this build to be compatible with a cross compiling procedure unless there is some combination of host/target/build arguments that I'm failing to set?