Aquarious12 wrote: ↑Sat Jan 15, 2022 11:01 am
Kott wrote: ↑Fri Jan 14, 2022 12:48 am
it's possible to pass llvm erors by
export INCLUDE_FAUSTDEV_BUT_NOT_LLVM="jadda"
but i can't compile it with recent Qt due absent of Qt5WebKit, using Qt5WebEngine is not ready yet
@Kott
hello friend thanks for reply.
as per your suggestion i did pass
export INCLUDE_FAUSTDEV_BUT_NOT_LLVM="jadda"
and moved forword with the compilation
but i can't compile it with recent Qt due absent of Qt5WebKit, using Qt5WebEngine is not ready yet
i think i have not recived anything based on Qt as error, please check a nd let me know if there is anything you can help with.
Code: Select all
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /usr/bin/dd
checking how to truncate binary pipes... /usr/bin/dd bs=4096 count=1
checking for mt... no
checking if : is a manifest tool... no
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for gcc option to accept ISO C99... none needed
checking whether __clang__ is declared... no
checking whether __INTEL_COMPILER is declared... no
checking whether __SUNPRO_C is declared... no
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking if gcc supports -Werror=unknown-warning-option... no
checking if gcc supports -Werror=unused-command-line-argument... no
checking if gcc supports -Wall... yes
checking if gcc supports -Wpointer-arith... yes
checking if gcc supports -Wmissing-declarations... yes
checking if gcc supports -Wformat=2... yes
checking if gcc supports -Wstrict-prototypes... yes
checking if gcc supports -Wmissing-prototypes... yes
checking if gcc supports -Wnested-externs... yes
checking if gcc supports -Wbad-function-cast... yes
checking if gcc supports -Wold-style-definition... yes
checking if gcc supports -Wdeclaration-after-statement... yes
checking if gcc supports -Wunused... yes
checking if gcc supports -Wuninitialized... yes
checking if gcc supports -Wshadow... yes
checking if gcc supports -Wmissing-noreturn... yes
checking if gcc supports -Wmissing-format-attribute... yes
checking if gcc supports -Wredundant-decls... yes
checking if gcc supports -Wlogical-op... yes
checking if gcc supports -Werror=implicit... yes
checking if gcc supports -Werror=nonnull... yes
checking if gcc supports -Werror=init-self... yes
checking if gcc supports -Werror=main... yes
checking if gcc supports -Werror=missing-braces... yes
checking if gcc supports -Werror=sequence-point... yes
checking if gcc supports -Werror=return-type... yes
checking if gcc supports -Werror=trigraphs... yes
checking if gcc supports -Werror=array-bounds... yes
checking if gcc supports -Werror=write-strings... yes
checking if gcc supports -Werror=address... yes
checking if gcc supports -Werror=int-to-pointer-cast... yes
checking if gcc supports -Werror=pointer-to-int-cast... yes
checking if gcc supports -pedantic... yes
checking if gcc supports -Werror... yes
checking if gcc supports -Werror=attributes... yes
Package xorg-macros was not found in the pkg-config search path.
Perhaps you should add the directory containing `xorg-macros.pc'
to the PKG_CONFIG_PATH environment variable
Package 'xorg-macros', required by 'virtual:world', not found
checking whether make supports nested variables... (cached) yes
checking whether to build developer documentation... yes
checking for doxygen... no
configure: WARNING: doxygen not found - documentation targets will be skipped
configure: WARNING: dot not found - doxygen targets will be skipped
checking for CHECK... no
checking for XCBPROTO... yes
checking for NEEDED... no
configure: error: Package requirements (pthread-stubs xau >= 0.99.2) were not met:
Package 'pthread-stubs', required by 'virtual:world', not found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables NEEDED_CFLAGS
and NEEDED_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
make: *** [Makefile:837: bin/packages/deletemetorebuild] Error 1
i installed
from Aur and was able to build the packages ,now going forward with build.sh. will update what happens.
Code: Select all
packages successfully built. Now run ./build_linux.sh -j7
after doing above commands i arrived at
Code: Select all
In function ‘raw_string_hash’,
inlined from ‘make_symbol_with_length’ at bin/packages/s7/s7.c:7899:10,
inlined from ‘make_symbol’ at bin/packages/s7/s7.c:7922:10,
inlined from ‘s7_define_variable’ at bin/packages/s7/s7.c:10920:9,
inlined from ‘init_rootlet’ at bin/packages/s7/s7.c:96667:3,
inlined from ‘s7_init’ at bin/packages/s7/s7.c:97044:3:
bin/packages/s7/s7.c:7806:7: warning: ‘memcpy’ reading between 1 and 8 bytes from a region of size 0 [-Wstringop-overread]
7806 | memcpy((void *)cy, (void *)(key + 8), (len > 8) ? 8 : len); /* compiler complaint here is bogus */
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Radium compiled. (127s)
[musicarch@musicArch radium-6.9.97]$ ls
amiga ladspa_info
a.out libgc.supp
api linux_objs
audio macosx
bench_faust.sh Makefile
bin Makefile.dummies
build_linux_common.sh Makefile.Qt
build_linux_gtk_visual.sh Makefile.Qt_old
build_linux_qt_visual.sh Makefile.X11
build_linux.sh makescript.sh
buildtype.opt midi
Changelog mixergui
check_dependencies.sh mmd2loader
check_install_dependencies.sh OpenGL
common pluginhost
compile_to_tmp.sh posix
config Qt
COPYING Qt47supp.txt
crashreporter QtWebKit_remove_plugins.patch
dependencies_ok README
dummies run_gdb.sh
embedded_scheme SanitizerSuppr.txt
find_moc_and_uic_paths.sh smakefile.smk
find_python_path.sh test
fix_faust_code.sh thesmakefile.smk
flagopts.opt unused_files
grep_touch_files.sh valgrind-python.supp
GTK weakjack
install.sh windows
issue_template.md X11
[musicarch@musicArch radium-6.9.97]$ install.sh
bash: install.sh: command not found
[musicarch@musicArch radium-6.9.97]$ ./install.sh
+++ readlink -f ./install.sh
++ dirname /home/musicarch/Radium/radium-6.9.97/install.sh
+ THIS_DIR=/home/musicarch/Radium/radium-6.9.97
+ PREFIX=
+ [[ '' = /* ]]
+ echo ' is not an absolute path'
is not an absolute path
+ exit -2
[musicarch@musicArch radium-6.9.97]$ run_gbd.sh
bash: run_gbd.sh: command not found
[musicarch@musicArch radium-6.9.97]$ ./run_gbd.sh
bash: ./run_gbd.sh: No such file or directory
[musicarch@musicArch radium-6.9.97]$ ./run_gdb.sh
/home/musicarch/Radium/radium-6.9.97/bin/packages/libxcb-1.13/src/.libs: directory
./run_gdb.sh: line 38: gdb: command not found
radium_progress_window: no process found
radium_crashreporter: no process found
i am having problem to start the application.i guess
anyone can suggest what should i do next.
this is what i refered , mentioned in github also
Code: Select all
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!! PLEASE DON'T ATTEMPT NOT TO USE ANY OF THE PACKAGES IN THIS DIRECTORY !!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Replacing anything in here will MOST LIKELY make Radium UNSTABLE in (more or less) subtle ways.
There are VERY good reasons for all of the packages included here.
Here are the reasons for including the packages you find in this directory:
1. Modified versions of upstream. (faust2, fluidsynth, gc/libatomic, libgig, libpd, qhttpserver, QScintilla, and Visualization-Library)
(Yes, patches have been provided upstream.)
2. Almost no, or no, distributions provide the package (faust2, libpd, qhttpserver, qtstyleplugins, s7, and Visualization-Library).
(Most of these overlap with the packages in point 1.)
3. Needs to be compiled with custom options. (s7, Visualization-Library)
4. Radium requires a newer version that not all distributions provide. (libxcb/xcb-proto).
In the case of libxcb, linking to older versions of libxcb.so WILL CRASH Radium for many users.
Using an older version of libxcb is probably the most common reason Radium has crashed.
And I know this because I get an email with backtrace every time a user presses the "Send" button in the crash reporter window, which pops up when Radium crashes.
After including libxcb with the program, all crash reports caused by libxcb suddenly disappeared.
But if you know that the system version of libxcb is at least 1.12, the package can probably be safely removed.
In addition, it's generally better that the users of a program use the same versions of 3rd party libraries as the developer(s).
This increases stability, but it is currently not the reason for any of the packages in this directory. However, if Qt, for instance, were less stable,
I would consider including Qt in this directory to make sure everyone used the same version of Qt. Luckily, though, Qt is relatively stable.
Same goes for libsamplerate, libsndfile, libjack, etc. etc. But in the future, other packages might be included here just as a general precaution.
Also, it's not unusual for larger software to include custom version of other packages.
In fact, it's very common, and for good reasons, as I've explained a little bit above.
Even packages included in Radium have themselves other packages included (Visualization-Library, JUCE, and probably others).
Regarding negative feedback I have gotten about the content of this directory from package distributors and others
------------------------------------------------------------------------------------------------------------------
First of all, there are several packages included with Radium in other directories than this one (with good reasons for those as well).
But for some reason, people are hung up on the specific packages included in this directory. Could it be because
the explicit step called "make packages" in the build process would make it seem like the author of Radium
tries to step on the toes of package managers? Well, that's not my intention. I guess the problem would be solved if there wasn't
an explicit "make packages" step, and instead "make packages" was baked into the "./build_linux.sh" script?
Because that's how most builds handle included packages, although one step has several disadvantages (more magic).
But I guess keeping piece is more important. Anyway, if you are making a Radium package for a Linux distribution,
it shouldn't be too hard without getting angry. Just do the following:
BUILDTYPE=RELEASE RADIUM_QT_VERSION=5 make packages
BUILDTYPE=RELEASE RADIUM_QT_VERSION=5 ./build_linux.sh -j `nproc`
./install.sh /opt
TARGET=/usr/bin/radium
echo "#!/bin/env bash" > $TARGET
echo "QT_QPA_PLATFORM_PLUGIN_PATH=\"$($(RADIUM_QT_VERSION=5 ./find_moc_and_uic_paths.sh qmake) -query QT_INSTALL_PLUGINS)\" /opt/radium/radium \"\$@\"" >> $TARGET
chmod a+rx $TARGET
And if "make packages" or "./build_linux.sh" fail, at least send me a bug report before complaining publicly about the build system of Radium.
There shouldn't be a rational reason to do anything else (except that I would prefer that you distribute the official binary demo packages instead,
which would also save you a lot of work). There's no reason to try using system versions of things you find deep into the Radium source code
that might resemble something your Linux distribution already provides. It will probably make Radium (more) unstable if you attempt to do so.
And there's no need to try to minimize the size of the package by removing apparently unused files. Computers have big harddrives these
days, and the same goes for the web servers. If your distribution has a rule against including modified versions of already existing
packages within a package (make sure you haven't misunderstood this rule), you should either ignore this rule, or use a different Linux distribution.
To sum up: Don't make life harder than necessary.
on my part after TARGET nothing is doing any changes or helping me in doing anything , i might be doing something different .
please do tell me, what should i do
@Kott