I am working with the latest gomobile, Go, and Android Studio builds.
When I run the gradle tasks from the terminal they work as expected and build the correct binaries, however from within Android Studio I receive an error:
bin/gomobile: toolchain out of date, run `gomobile init`
Of course I have re run gomobile init many times and no change. My assumption is that Android Studio is using some config that I can not identify.
I appreciate this is a somewhat edge case question, but if anyone can point me in the right direction it would be helpful.
TLDR; ./gradlew myproj:bind works fine in terminal, fails in Android Studio.
I have gotten to the bottom of this in case anyone else has the issue;
It appears, at least for me, the Gradle plugin wasn't respecting the location of the GO bin. Instead it looks up the gobin using;
gobin, err := exec.LookPath("go")
I have a number of Go versions installed (for various reasons) so my forcing the gobin was failing. To discover this I have added debug logs to the env.go file. In general the logging on the file is not the most clear when attempting to debug.
This seems to be a gomobile error message, seen in cmd/gomobile/env.go#L69-L83:
// Find gomobilepath.
gopath := goEnv("GOPATH")
for _, p := range filepath.SplitList(gopath) {
gomobilepath = filepath.Join(p, "pkg", "gomobile")
if _, err := os.Stat(gomobilepath); buildN || err == nil {
break
}
}
verpath := filepath.Join(gomobilepath, "version")
installedVersion, err := ioutil.ReadFile(verpath)
if !bytes.Equal(installedVersion, version) {
return nil, errors.New("toolchain out of date, run `gomobile init`")
}
So double-check the value of GOPATH between your local session and your Android Studio session.
See for instance this old (2015) thread to see if any of those comments still apply.
Related
I wrote a python script which runs some Modelica scripts file for Gitlab pipeline continuous integration. I could get the python script to work from command line without any issues, however, whenever I trigger the pipeline in Gitlab, I got errors below, I am curious if anyone encountered similar issues and could provide a solution possibly?
No compiler selected. Please select a version of Visual C++ or GCC. For instructions on how to install a supported compiler, please visit www.dymola.com/compiler.
I tried to use SetDymolaCompiler method, but it still gives me the same error.
(BTW, the documentation in the python interface was incorrect. In the documentation, string lists (see marco's answer and my correction) were used to set compiler location, however, I figured that it should be a map actually).
Here's the code I was running:
dymola_obj = None
try:
dym_obj = DymolaInterface(dymola_exe)
dym_obj.cd(mc_work_dir)
dym_obj.SetDymolaCompiler("vs", {"CCompiler":"MSVC","MSVCDir":"C:/Program Files (x86)/Microsoft Visual Studio 11.0/Vc"})
success = dym_obj.ExecuteCommand("some command")
except DymolaException as ex:
success = False
finally:
if dym_obj is not None:
dym_obj.close()
dym_obj = None
return success
OS: Win 10 Pro (on a VM)
Dymola: 2018 FD01
Correction:
Python interface documentation is still incorrect, in order to change compiler settings one should use [] instead of { }.
Python interface documentation:
SetDymolaCompiler("vs", {"CCompiler=MSVC","MSVCDir=C:/Program Files (x86)/Microsoft Visual Studio 10.0/Vc"});
Should be changed to:
SetDymolaCompiler("vs", ["CCompiler=MSVC","MSVCDir=C:/Program Files (x86)/Microsoft Visual Studio 10.0/Vc"]);
I didn't try with gitlab, but I found an error when running your code on my machine with Dymola 2018 FD01 and python 2.7.
In fact SetDymolaCompiler really does require a list of strings. You have to replace the line
dym_obj.SetDymolaCompiler("vs", {"CCompiler":"MSVC","MSVCDir":"C:/Program Files (x86)/Microsoft Visual Studio 11.0/Vc"});
with
dym_obj.SetDymolaCompiler('vs', ['CCompiler=MSVC', 'MSVCDir="C:/Program Files (x86)/Microsoft Visual Studio 11.0/Vc'])
Some tips when working with the python interface:
activate the Dymola window during development with
DymolaInterface(showwindow=True)
set breakpoints and check after every command what Dymola writes to the command window. In your case it got obvious that SetDymolaCompiler was not executed due to syntax errors and the compiler was not set
And finally, your minimal example does not work, as python code lines must not end with ;
This is a follow up to this previous question of mine.
Here is the (simplified) location in that qmake script that causes problems (I'm currently testing only this particular library but I've also checked and the same issue is present with the others too):
VTK_API = ""
CONFIG(debug, debug|release) {
message(Application will be built in DEBUG mode)
VTK_API = $$(VTK_DBG_DIR)
}
else {
message(Application will be built in RELEASE mode)
VTK_API = $$(VTK_DIR)
}
I've moved my qmake project file to Linux to check how it's working there. And for my surprise the environment variables are not read properly that is when I output the value from the given variable it's empty. I've adjusted the paths for both versions of the library since I have a different naming of the respective environment variables (in .bashrc) that point at the location of its debug and release builds.
user#debian:~$ echo $VTK_DBG_DIR
/opt/vtk-dbg/lib
user#debian:~$ echo $VTK_DIR
/opt/vtk/lib
As you can see the variables are properly echoed in my terminal. I also have to add that I start my Qt Creator from my bash terminal due to some other things that I want loaded along with the IDE so the case "Your variables are not read since Qt Creator doesn't read what's in your .bashrc" is not present here.
Any idea what's going on here? Is there a difference in the way the loading of environment variables works in qmake based on the operating system or am I missing something else here (an error in my script perhaps)?
Everytime I double click winghci.exe an error message CreateGHCiProcess failed with failed with error 2 pops. I assume the installation hasn't completed setting environment variables successfully since cmd C:\>ghci ends up with no command found either. Could anyone help posting changes that might take place during the installation or any solution to this?
To complete the incomplete answer: add the path of the bin directory inside your haskell platform folder, e.g. C:\Programs\Haskell Platform\2012.2.0.0\bin, to your PATH. That should be all.
Issue closed. Solution is to set $PATH$ by either reinstallation or manual
I think that's supposed to be %PATH% when you're dealing with windows. path = c:\programs\Haskell Platform\2012.2.0.0\bin;%path% for your example.You could also make a shortcut and point the "Start in:" entry at where you've installed the bin directory.For me, I have it installed under "c:\users[ME]\my documents\dev\Haskell Playform\2013.2.0.0\bin"Starts up fine.
I have been trying in the last days to understand how qmake works buy I'm stuck.
I want a project with the following structure:
root
bin
testjson
lib
libjson.so
src
testjson.cpp
All i wanted was to test the json library. I have created a new empty project in Qt Creator 2.3.0, and set up all the settings so the executable will run. Tested what I wanted and closed the application.
Later, when I opened Qt Creator again, I loaded the .pro file and surprise, when I try to run the project I get this message: "No executable specified." :| In this case I went to the project tab, and selected the executable manually but, as expected, when I tried to run it, I got this message "error while loading shared libraries: libjson.so: cannot open shared object file: No such file or directory". It was expected since the LD_LIBRARY_PATH is not set(it's like i'd run it from cli).
It looks like the .pro file isn't parsed properly because the 1st time, on the project tab when I was selectig Run tab, I'd see a message : "Parsing .pro file", and then the running config would get filled, and greyed out, so it means that the LD_LIBRARY_PATH was added by Qt Creator after parsing the .pro file.
Now my questing is: why was the .pro file parsed correctly 1st time?
Here's the .pro file:
!include(../../common.pri){
error(Couldn't find the common.pri file!)
}
TEMPLATE = app
SOURCES += testjson.cpp
CONFIG += console
TARGET = testjson
CONFIG(release, debug|release) {
DESTDIR = $$BinaryDir/Release
} else {
DESTDIR = $$BinaryDir/Debug
}
LIBS += -L$$LibraryDir -ljson
INCLUDEPATH += $$DefaultInclude
DEPENDPATH += $$LibraryDir
PS: The solution is to manually add the LD_LIBRARY_PATH to the building environment, but I find this not the right way to do it.
I think you have confusion between what is controlled by the qmake (.pro) file and what is controlled by your runtime environment. The .pro file is only specifies the BUILD environment, not the runtime environment. The .pro file is only used during the build process.
When you go to run the built code, whether from a command line or from within Qt Creator, you are dealing with the RUNTIME environment. If you tried running the program from the shell, you would have to specifically specify the LD_LIBRARY_PATH. From within Qt Creator, you will have to do the same thing.
[I only have Qt Creator 2.2 installed here, but it should be very similar in 2.3]
To set the runtime environment,
Select the Projects icon in the left tool bar.
On the top, select "Run Settings"
On the Run Settings page, go down to the "Run Environment" settings and click "Details" to show the details of the environment.
Click on "Add..." and add "LD_LIBRARY_PATH" with the appropriate settings.
When you are done, the setting will be stored with your project. [The settings are actually stored in a file with a ".user" ending, not the ".pro" file.]
When you go to run your project, the environment you setup under "Run Settings" will be used, and you application should start with the correct LD_LIBRARY_PATH.
If you don't want to manually add path to LD_LIBRARY_PATH in Qt, qmake has a variable for that, it's called QMAKE_LIBDIR. In my case I couldn't link the OpenCV libraries installed in a custom path (not in /usr) but this answer unblocked me. Basically this line tells Qt/qmake to look for libraries where you want it to:
QMAKE_LIBDIR = /path_to_your_libs
when trying to install cygwin, I keep getting this error message:
the entry point
rl_filename_rewrite_hook could not be
located in the dynamic link library
cygreadline7.dll
Has anyone seen this before ?
Thanks
I had the same error with cygwin1.dll. I checked in c:\cygwin\bin and noticed there were two files, cygwin1.dll and cygwin1.dll.new (possibly from a failed or aborted setup run?). The ".new" version was in fact newer (and slightly larger) than the existing cygwin1.dll, so I replaced cygwin1.dll with cygwin1.dll.new, and ran setup again. It completed with no errors.
First idea is to try reinstalling libreadline7 (or similarly named package) using the cygwin installer. Use the search field to enter readline to make it easier to find the right package.
Another option is that in the cygwin installer, change form Curr to Prev in order to switch to the previous-stable release. This means lots and lots of downloading and reinstalling. I anctually did manage to provoke my error into becoming a libreadline7 error, and switching to Prev at least got rid of the error messages. (Yay! Now bash, ssh server and git is working again! Back to work here then...)
Please check your path in WINDOWS (advanced system properties) environment. I found that C:\WinAVR\bin was coming before my cygwin path, so I moved that to the end, fixed my issue.
If you have multiple CYGWIN1.DLL files in your system, it definitely causes headaches if you're not careful.