I am building Qt6 for STM32MP157
Qt sources downloaded v6.1.2
Platform: Ubuntu 18.04.5 LTS
STM32 SDK version: v2.0.0
The same build succeed for host machine (to generate qt host tools)
But when I run it with toolchain file for stm32mp157, it fails with error by perl on syncqt.pl line 55:
use English qw(-no_match_vars );
The error message is as follows:
-- Running syncqt for module: 'QtCore'
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_MEASUREMENT = "ur_PK",
LC_PAPER = "ur_PK",
LC_MONETARY = "ur_PK",
LC_NAME = "ur_PK",
LC_ADDRESS = "ur_PK",
LC_NUMERIC = "ur_PK",
LC_TELEPHONE = "ur_PK",
LC_IDENTIFICATION = "ur_PK",
LC_TIME = "ur_PK",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
Can't locate English.pm in #INC (you may need to install the English module) (#INC contains: //usr/lib/perl5/site_perl/5.30.1 //usr/lib/perl5/vendor_perl/5.30.1 //usr/lib/perl5/5.30.1 /opt/st/stm32mp1/3.1-openstlinux-5.4-dunfell-mp1-20-06-24/sysroots/x86_64-ostl_sdk-linux/usr/lib/perl5/site_perl/5.30.1/x86_64-linux /opt/st/stm32mp1/3.1-openstlinux-5.4-dunfell-mp1-20-06-24/sysroots/x86_64-ostl_sdk-linux/usr/lib/perl5/site_perl/5.30.1 /opt/st/stm32mp1/3.1-openstlinux-5.4-dunfell-mp1-20-06-24/sysroots/x86_64-ostl_sdk-linux/usr/lib/perl5/vendor_perl/5.30.1/x86_64-linux /opt/st/stm32mp1/3.1-openstlinux-5.4-dunfell-mp1-20-06-24/sysroots/x86_64-ostl_sdk-linux/usr/lib/perl5/vendor_perl/5.30.1 /opt/st/stm32mp1/3.1-openstlinux-5.4-dunfell-mp1-20-06-24/sysroots/x86_64-ostl_sdk-linux/usr/lib/perl5/5.30.1/x86_64-linux /opt/st/stm32mp1/3.1-openstlinux-5.4-dunfell-mp1-20-06-24/sysroots/x86_64-ostl_sdk-linux/usr/lib/perl5/5.30.1 .) at /home/dyasin/repos/qt6/qtbase/libexec/syncqt.pl line 55.
BEGIN failed--compilation aborted at /home/dyasin/repos/qt6/qtbase/libexec/syncqt.pl line 55.
CMake Error at qtbase/cmake/QtModuleHelpers.cmake:206 (message):
Failed to run syncqt, return code: 2
Call Stack (most recent call first):
qtbase/src/corelib/CMakeLists.txt:29 (qt_internal_add_module)
-- Configuring incomplete, errors occurred!
See also "/home/dyasin/repos/qt6/build/CMakeFiles/CMakeOutput.log".
See also "/home/dyasin/repos/qt6/build/CMakeFiles/CMakeError.log".
Where it fails to load English.pm
I have noticed a pecularity that perl uses a different version when compiling for stm. So the build system is using perl from stm SDK. And STM SDK has no English.pm
my question is how we can use perl from host system?
My mistake. In my toolchain file, I had overridden the "CMAKE_PROGRAM_PATH" to find SDK compiler and other programs, I had to adjust it so that it could find perl from host system.
Related
I am trying to install and configure Globus Connect Personal for Linux (i have a CentOS 8), following this tutorial. However, when I try to set up Globus connect personal by running ./globusconnectpersonal -start i get this error
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Python path configuration:
PYTHONHOME = (not set)
PYTHONPATH = (not set)
program name = 'gc.py'
isolated = 0
environment = 1
user site = 1
import site = 1
sys._base_executable = ''
sys.base_prefix = '/tmp/build/80754af9/python_1599203911753/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placeho'
sys.base_exec_prefix = '/tmp/build/80754af9/python_1599203911753/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placeho'
sys.executable = ''
sys.prefix = '/tmp/build/80754af9/python_1599203911753/_h_env_placehold_
Subprocess pid 1722896 exited, rc=1
Traceback (most recent call last):
File "./gc-ctrl.py", line 369, in <module>
start(debug=False)
File "./gc-ctrl.py", line 191, in start
send2clients(fds[2:], mesg.encode('utf-8'))
AttributeError: 'bytes' object has no attribute 'encode'
does anybody know what this could mean?
I think there needs to be PYTHONHOME and PYTHONPATH. I created a conda environment with just the correct version of python in it. Then I ran ./globusconnectpersonal inside the conda environment.
Using a conda environment also works for the non-GUI form of globus.
I have not tried setting the paths manually.
I ran into the same problem when I was using Python3.8 in a Miniconda environment. When I disabled conda with:
conda deactivate
Then I could run "globusconnectpersonal -start" with my native Python2.7. I don't know if it was because the client needed Python2 or if conda was interfering, but his resolved the problem for me.
I'm attempting to use sparklyr to analyze a large dataset in R. Upon my attempts to establish a Spark connection with spark_connect, I receive the following error:
Error in get_java(throws = TRUE) : Java is required to connect to Spark. JAVA_HOME is set but does not point to a valid version. Please fix JAVA_HOME or reinstall from: https://www.java.com/en/
I've reinstalled Java but continue to get the same error. Any advice?
When I run:
sparklyr:::get_java()
java
"/usr/bin/java"
It appears that you don't have java set up in such a manner that the response for that sparklyr function is satisfactory. Unlike #Kerie I get nothing from the echo command. Instead, I can get sensible results from this command in a Terminal session:
$ java -version
#-------------------
java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
Running MacOS 10.11.6 (not upgraded because my hardware is "obsolete" per Apple) and R 3.5.1.
There's an irony here in that it appears that the get_java function is supposed to set a value for the location if it cannot find an environment variable. Here's the code:
sparklyr:::get_java
#----------
function (throws = FALSE)
{
java_home <- Sys.getenv("JAVA_HOME", unset = NA)
if (!is.na(java_home)) {
java <- file.path(java_home, "bin", "java")
if (identical(.Platform$OS.type, "windows")) {
java <- paste0(java, ".exe")
}
if (!file.exists(java)) {
if (throws) {
stop("Java is required to connect to Spark. ",
"JAVA_HOME is set but does not point to a valid version. ",
"Please fix JAVA_HOME or reinstall from: ",
java_install_url())
}
java <- ""
}
}
else java <- Sys.which("java")
java
}
<bytecode: 0x7fb5c7f2db30>
<environment: namespace:sparklyr>
Because I do not have an environment variable for JAVA_HOME, but do have java registered with which, the get_java function returns a valid path. So my system returns:
Sys.which("java")
java
"/usr/bin/java"
From comments by #user6910411, I am reminded that you should not update to the current Java Dev Kit (which is 1.9), but do rather use the link provided by #Kerie to the prior major version, 1.8. You should also run:
Sys.unsetenv("JAVA_HOME")
to get rid of the misleading symlink. Or perhaps you could track it down at /Library/Java/Home (if that's where it is) and delete it before installing the newer (but not newest) version.
Run echo $JAVA_HOME in terminal, and see what is the output.
In my Mac OS, the output is :
/Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home
I want to call an R script using Java. I am trying the JRI method to call the R script. However my JVM gets terminated when creating an Rengine.
I am running one of the examples which has been provided alongside rJava library installation in R.
Code I have tried
Version 1:
`Rengine re=new Rengine(args, true, new TextConsole2());`
Version 2:
`Rengine re=new Rengine(args, false, new TextConsole());`
Version 3:
`Rengine re = new Rengine(new String[] { "--vanilla" }, false, null);`
All three have terminated the JVM while they were getting executed.
I am using STS 3.9.1 and have exposed the below variables before running the Java program
java.library.path - pointing to the r java dll's
R_HOME - pointing to the R.exe
PATH - reinforcing the systems path with the paths of rJava dll's and R.exe
I am using R-3.5.0, followed all steps as per
Study Trails - R and Java
and Mavlarn - R and Java but still facing the same issue.
What could I be doing wrong ?
I keep getting the following error message in the R Markdown log:
cropping document_files/figure-latex/ranking_time_output-1.pdf
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LC_ALL = (unset),
LC_CTYPE = "en_NL.UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
I've tried numerous things, such as:
Sys.setlocale("LC_ALL", 'en_US.UTF-8')
Sys.setenv(LANG = "en_US.UTF-8")
Sys.setlocale("LC_MESSAGES", 'en_GB.UTF-8')
running in R. However, non of this seems to work.
Do I have to do something in the command line or is it an issue that I can fix in R? I'm not an expert in both, so would appreciate help!
RStudio version: 0.99.903, system: Mac OS X 10_11_6
Furthermore I'm located in the Netherlands, but I run everything on my system in English.
LC_CTYPE is set to "en_NL.UTF-8". Such a locale does not exist on Mac OS X (and probably no other OS). Try to find where the wrong setting comes from because it will probably cause other problems, too.
Setting the locale with Sys.setlocale() is useless because Perl is running in a child process created with fork() and exec() and then switches locale based on the process environment.
Setting the environment for the Perl process is probably the right approach but you have to overwrite the erroneous value LC_CTYPE, not LC_ALL:
Sys.setenv(LC_CTYPE = "en_US.UTF-8")
You can set those environment vars by:
sudo vi /etc/environment
add these lines
LANG=en_US.utf-8
LC_ALL=en_US.utf-8
I'm trying to use koRpus in R to do lemmatization on a Linux server running RHEL6. Last week when I had MRO (Microsoft R Open) 3.2.3 installed the code below worked great:
library(koRpus)
lw = c("dancing","flying","flew")
res = treetag(lw,treetagger="manual",format="obj",TT.tknz = F, lang="en",
TT.options=list(path="/usr/local/bin/TreeTagger",preset="en"))
Now that I'm running MRO 3.3.0 though I get the following error:
Error in grepl("(^\\p{P}*\\p{L}\\p{M}*\\.)", tkn, perl = TRUE) :
invalid regular expression '(^\p{P}*\p{L}\p{M}*\.)'
In addition: Warning message:
In grepl("(^\\p{P}*\\p{L}\\p{M}*\\.)", tkn, perl = TRUE) :
PCRE pattern compilation error
'support for \P, \p, and \X has not been compiled'
at 'p{P}*\p{L}\p{M}*\.)'
OK, so that means my PCRE needs to be recompiled with unicode support. In fact when I run the code below I see that's the exact issue. I also see that I'm running version 8.37.
pcre_config()
#> UTF-8 Unicode properties JIT
#> TRUE FALSE FALSE
extSoftVersion()
#> zlib bzlib xz
#> "1.2.8" "1.0.6, 6-Sept-2010" "5.2.2"
#> PCRE ICU TRE
#> "8.37 2015-04-28" "57.1" "TRE 0.8.0 R_fixes (BSD)"
#> iconv
#> "glibc 2.12"
Now, I went ahead and installed 8.39 and with (hopefully) the right flags set.
./configure --enable-utf8 --enable-unicode-properties
make
make install
So now when I run pcretest -C I get
PCRE version 8.39 2016-06-14
Compiled with
8-bit support
UTF-8 support
Unicode properties support
No just-in-time compiler support
Newline sequence is LF
\R matches all Unicode newlines
Internal link size = 2
POSIX malloc threshold = 10
Parentheses nest limit = 250
Default match limit = 10000000
Default recursion depth limit = 10000000
Match recursion uses stack
But when I launch R again my pcre_config() yields identical results, the treetag call fails identically and extSoftVersion() still reports 8.37.
What do I need to do for R to start using the new PCRE version?
Deeper and deeper...
R apparently no longer ships with PCRE (per https://mran.microsoft.com/news/#r330) as of 3.3.0 so it (supposedly) relies on the system PCRE installation. I went through the server and removed every PCRE file identifiable (complete uninstallation) and R still reports PCRE 8.37 2015-04-28 which suggests the MRO 3.3.0 for RHEL 6 includes PCRE despite claiming otherwise. Additionally, the grepl command still fails with the error too, so it's not just an issue with extSoftVersion.