I'm having problems compiling applications with remote ant, something similar to this. However the flex compiler seems to have problems with this. When I run the same script on my local compiles everything without any problems but when I try the remote ant it fails without giving more information.
Things to look for on the remote machine:
The paths in the build file need to be valid (I'm pretty sure the script file you use to build the project on your computer, will not be good on the remote one because of a possible difference in paths)
You need the Flex SDK installed
You need Java JDK installed
You might also need some environment variables set correctly (like JAVA_HOME)
ANT binaries on the remote machine (but I assume you already have this, probably coming with the system you're using)
The sources to be compiled, obviously (I assume you already have these too, probably gotten by your system from a repository)
Also I find it hard to believe it would fail without any error. There should be at least a log file somewhere to give you an idea of what went wrong.
Related
I've cross compiled Qt and created SD card image and mounted using losetup. Compiation is much faster now compared to direct sshfs mount. Application runs OK. Now, I want to debug which is dead slow and it appears like it is copying the files back to the dev machine for debugging. I see this suggestion:
File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
I'm using gdb-multiarch and have got gdbserver (on target board).
I'm kind of lost here. Where to set this option? I've supplied --sysroot argument to the binary but no use. Any help is really appreciated.
Update: using Qt Creator for the development.
sysroot is a gdb setting. You can set it in gdb with the set sysroot command. For example:
(gdb) help set sysroot
Set an alternate system root.
The system root is used to load absolute shared library symbol files.
For other (relative) files, you can add directories using
`set solib-search-path'.
This setting controls how gdb tries to find various files it needs, and in particular the executable and shared libraries that you are debugging.
Recent versions of gdb default sysroot to target:, which means "fetch the files from the target". If you're debugging locally, this is just local filesystem access; but if you are debugging remotely and have a slow connection, this can be a bit painful. In order to make this faster, the idea is to keep a local copy of all the files you'll need, and then use set sysroot to point gdb at this local copy.
The main issue with this approach is that if your local copy is out of sync with the remote, you can end up confusing gdb and getting nonsense results. I am not certain but maybe enabling build-ids alleviates this problem somewhat (certainly in theory gdb can detect build-id mismatches and warn, I just don't recall whether it actually does).
As Tom Tromey suggested adding set sysroot {my sysroot local path} as a starting command in the debugger has worked for me.
I'm getting crazy with a bad memory access in a qt program when i'm using qglwidget::rendertext function. My program is super simple, I'm only one pointer, but the crash doesn't seem relate to that because the debugger stops sometimes when i call rendertext, sometimes when i close the programs. i'm not experienced c++ programmer and this is getting me crazy.
but i've found this BUG REPORT. It seems recent (Updated: 25/Apr/13 8:47 AM) and due to the fact I don't know what to do with this bad memory access i think it worths to give it a try.
the solution patch is posted here but i don't know what to do.. do i have to recompile all qt 4.8? only the opengl part? can i avoid to recompile everything?
Go to the directory where you compiled Qt and change the file qt/src/opengl/qpaintengine_opengl.cpp. Make the changes that the author made, or download the author's file and replace it in your source directory. Change directory to the main qt directory and run make. Be sure not to re-run ./configure before you do the make or it will rebuild the whole thing.
After make has finished, run sudo make install and it will put the newly compiled QPaintEngine module into your install directory. Unfortunately, I don't know if this will work if you have a number of configurations (like static libraries), but it's worth a try.
I have done this with modules in QtMobility hundreds of times. You also have to remember that you have a Frankenstein's Monster version of Qt now, and when you upgrade remember to re-patch if the change was not committed to the newest build.
Hope this helps.
I am involved in development of a large cross platform project that build for Windows, Linux, and Mac OS X. The build for the software is configured with CMake.
The CMake scripts have been designed to configure successfully for Visual Studio on Windows, and Makefiles are currently used for building on Linux and Mac OS X.
Pretty much all of the development for the project so far has been done with people working on Windows, and a little bit of work on Linux. I am interested in developing for the project using Xcode 4.6 on a Macintosh running Mac OS X 10.7, and I have encountering problems as the CMake files do not seem to configure properly for that development environment.
For non-windows platforms many custom commands have been written to try to configure things such as copying needed files or setting environments that are needed for certain operations such as running unit tests during the build process.
It seems that because Xcode is an integrated development environment simliar to Visual Studio is has this concept of a build configuration, and when software gets build output files in up in a directory path that includes that configuration concept (i.e. many build files end up in a path that ends with folder named something like Debug, Release, etc.)
CMake is supposed to have support for dealing with this build configuration concept and the mechanism utilized work well for Visual Studio. That do no seem to work for Xcode. For example our build engineers have design CMake scripts so that for Windows, many path and whatnot are configured using the CMAKE_CFG_INTDIR value which helps to qualify the build configuration.
The use of CMAKE_CFG_INTDIR is not working for Xcode as the script for Macintosh were written with Makefiles in mind which don't really have the build configuration concept. The use of CMAKE_CFG_INTDIR within custom commands used to configure things fails on the Macintosh as the value resolves to $(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME). This values are not define when the custom commands are run, so values are not set properly and build operations fail.
It is unclear what is needed so that the system can successfully configure for Xcode. Searching on the Internet so far has not yielded insight into what should be used to make sure that build configuration can be successful. What resources are available that would help in figuring out how to configure this project to build with Xcode?
If you're talking about custom commands set using add_custom_command, then you should prefer "generator expressions" to avoid issues regarding per-configuration build directories. From the docs for add_custom_command:
Arguments to COMMAND may use "generator expressions" with the syntax "$<...>". Generator expressions are evaluated during build system generation to produce information specific to each build configuration.
For example, the build directory for a target called "MyExe" could be referred to as $<TARGET_FILE_DIR:MyExe>
Generator expressions are available in a few CMake commands, not just add_custom_command.
If you have more specific problems, it's maybe worth asking further question(s) with the relevant details.
I am running mxmlc in the command-line with -incremental=true. Flex is building the cache file using a checksum the first time. Subsequent compilations fail with this message:
Failed to match the compile target with path_to_cache/projectname_329043.cache. The cache file will not be reused.
path_to_cache exists
the cache file exists in path_to_cache
the compiler is not trying to create a new cache file, so I assume it is generating the same checksum
My environment:
Flex 3.0
Mac - OSX 10.4.x
I just ran across this issue myself and after not finding the answer anywhere on the web, I bashed my head against mxmlc in practically trail-and-error until finding the answer. In my case, I was regenerating the flex config xml file each time I compiled from within ant. It turns out that this is the error you get in the case where it thinks the config has changed. You can test this by simply touching your config file and running against unmodified sources. So, if the timestamp is changing on your flex config.xml between compiles, that is likely the culprit.
It could be a permissions issue. Have you tried running with sudo? I wouldn't recommend doing that permanently, but if using sudo makes the error message go away, then you know it's a permissions issue; and you can move on to the proper way to resolve it.
You could also try going into Disk Utility and doing a check/repair of disk permissions. OSX has been notorious for needing this done occasionally.
I have developed a Java swing application, then I have deployed it through a .jar package.
I run my application on my PC double-clicking over the .jar file and everything goes fine, everything goes fine from command line (dos prompt) too.
Here my problem.
I have tried to run my app on another PC:
same OS (Windows XP)
same JRE (1.6.0_U13)
but Oracle JInitiator 1.3.1.18 installed (this is the only difference with my PC)
The app works fine only from command line, but not from gui!
Double-clicking over the .jar file I get this error:
`Could not find the main class. program will exit!`
Can this error be due to some conflict between JRE and JInitiator?
Does anybody had the same trouble?
Thanks
edit:
executing .jar files from gui is associated to the "javaw" command
It is probably a conflict with JInit, which changes the association between jar files and the java command used to launch them.
See this thread.
Re-installed java and the problem has gone away.
A quick description might be - jinitiator installs as a fully implemented JRE with some additional features for cached downloads when dealing with applets.
As all the JRE installers I've seen lately do, regardless of if they are new or old, they replace several entries in the registry to become the active JRE. Whatever you installed last will be run unless you provide a full path to java.exe or change the registry to re point at a different JRE.
examine:
HKEY_CLASSES_ROOT\jarfile\shell\open\command
and see if the path to javaw.exe is correct. (or even included)
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App
Paths\java.exe and javaw.exe and javaws.exe to check the path there also.
Have you checked your PATH/CLASSPATH/JAVA_PATH variables. It is possible that Jinitiator has installed the wrong version at the front.
Possibly check your manifest entries. See if the MANIFEST.MF in the jar contains the Main-Class attribute set correctly to the class that is supposed to be invoked, if not try setting it.