I've been building some Lua scripts to automate certain functions and configurations that I can use with my audio VST plug-ins. The scripts themselves work fine, tested in a separate project embedded in C++.
However, due to VST and VSTGUI needing to be build against the 10.6 SDK with Architectures set to Standard 32-bit/64-bit (and Valid architectures include i386 & x86_64), when I integrate it into the VST plug-in project, it ignores liblua.a for the i386 architecture, causing obvious linking errors.
Note: I can build the VST plug-ins for 64-bit only and eliminate the i386 arch, but then the plug-in won't load in some hosts. I think this has to do with some hosts still implementing only Carbon-based UI and how this works with VSTGUI.
Anyway, what kind of solutions exist for this problem? I can build Lua for either architecture, but not both. Unless I put them in separate directories and somehow tell Xcode about that?
It's not really a critical thing, but I'd like to be able to script some common elements between plug-ins. Thanks!
Related
I am new in the programming world and I am really glad that I have finished building my first program. Its a simple C++ game that I programmed in QT on Ubuntu. Now I want to create executable files which contain all the neccessary dependencies, so the program can be ran without having QT and the used libraries.
I've been reading through questions and forum posts for the last two days, but I cant get my head around the process. I know that in order to make the program executable it has to contain all the links to the .so files or the .dll on windows, but I have no idea how to convert from .so to .dll and how to include those into my program.
I really did look at a lot of posts and all of them seemed a bit too advance. Also the whole building, releasing, packaging, deploying processes are not clear to me, but I haven't found any decent information starting from scratch.Can you point me into the right direction ?
Thanks
I can't recommend enough not cross-compiling, get a virtual machine with your target OS and install the native toolchain plus any required libraries. This is simpler, less error-prone, and issues are easier to diagnose.
There's also the massive advantage that you can test the software on the platform you're building on. Remember you'll still need access to your target OS in order to test what you have built, so in reality cross-compiling offers you no advantage.
Of course everything I've said is irrelevant if you're building for an embedded OS whose toolchain is designed for cross-compilation anyway.
Get a cross-compiler installed on your linux machine, cross-compile Qt. Then cross-compile your code so it can generate executable for windows. I think MinGW has cross compilers for linux.
Check this out How do I configure Qt for cross-compilation from Linux to Windows target?
I am developing a framework for other iOS developers and I am using boost as a dependency. I am creating a boost.framework which contains the libraries (fat library) for arm6, arm7, arm7s, arm64, i386 and x86_64. Compilation and linking seems to work fine, but using my library and the boost.framework in XCode 5.0.2 in a simulator results in the following error
Detected an attempt to call a symbol in system libraries that is not present on the iPhone:
pthread_cond_init$UNIX2003 called from function _ZN5boost18condition_variableC2Ev
However, deploying the App on a device does not yield any problems at all.
After looking around I found a StackOverflow entry explaining that his $UNIX2003 function names are part of the OSX library. Based on that I checked the linking of the library and only the i386 parts of the library are linked against the $UNIX2003 parts (which is in accordance to Apple's own description). The arm* architectures are using the unsuffixed versions.
My question is, what can I do to have it running on the simulator? Do I need to recompile boost with specific flags? Is there an option to tell the simulator to shut up? Or is there at least I way to tell the simulator to use the actual device libraries not the i386 ones?
There is the possibility of writing these $UNIX2003 functions myself which then delegate to the real ones. But since there are quite a few function calls I would rather not do that, especially since the developers using my framework would need to do the same I guess (which I would like to avoid).
After coming across a discussion on an unrelated mailing list, I found the original culprit: The boost library was built against the Mac OS X version of (I guess libc++), not against the iPhone simulator version of it. Fixing this generated the framework in the proper formats as well as containing only links to the proper versions of the system calls.
My c++ app depends on GCC, MongoDB C++ driver and Boost. My current way is to keep the OS consistent. I develop C++ on Ubuntu 12.04 64bit Desktop, and deploy it on Ubuntu 12.04 64bit server. Also I should install the same version of dependencies on target server.
But If I want to develop my C++ app on Ubuntu 13.04 and use newest Boost, MongoDB driver and GCC 4.8.1, which way is easy to deploy C++ app on Ubuntu 12.04 server.
static linking
Dynamic linking, also deploy all dependencies to target server?
Which way is simple? Sometimes, I cannot compile libraries on target server.
If the dependencies are small easiest way is to compile everything statically. It is fairly easy during the build step, and nothing fancy is needed. However, with bigger libraries, and a bigger project this might get inconvenient.
I think that best practice would be to compile dependencies into shared objects ship them along the binaries and execute stuff in a way that ld will look for your stuff 1st. I think it's possible by for example using LD_LIBRARY_PATH e.g. LD_LIBRARY_PATH=/where/did/i/ship/lib:$LD_LIBRARY_PATH my_binary.
It can be somewhat cumbersome as you need to set up your build system to compile stuff as shared objects and properly pack everything.
I'm pretty sure some of the pre-compiled programs that are shipped for linux work this way. Strangely, I can't find any custom pre-compiled app under my hand at the moment.
It depends on your application. If your application consists of only one specific binary, then static linking of all C++ libraries is in order. You can safely link dynamically all C libraries, as the C ABI is unchanging; this just leaves you with version dependencies. However in most cases the major SO-Name verions are mostly compatible and libraries of differing major SO-Name can be installed in parallel. So I'd rely on the package manager to install those. C++ libraries are tricky due to lack of a common ABI. Even a mere compiler version bump can make them incompatible *sigh*.
We have some applications written in C/C++ and makefiles for the same. Currently, we are using the GNU make system on windows (cygwin based). The makefiles were written long back considering only Windows OS in mind. Now we are going to revamp everything.
I am unaware of the factors to be considered while writing the makefiles so as to make them cross platform compatible. I looked at some Sources on the Internet, but they were unsatisfactory. Can someone please list out the issues to be considered while writing the makefiles so as to make them compatible across various platforms.
PS: I have seen this link, but i think it isn't what i want.
Makefiles and cross platform development
You can use cmake - it's a cross platform tool which generates makefiles or projects files with respect to your platform. So instead of writing Makefile you write CMakeLists.txt, then you run cmake and it will generate Makefiles. When you want to compile your program on another platform you just ru-run cmake with different target project system.
How can i run a program which already has been built and compiled before on Qt IDE, so that i can take that program and run on any computer I want without recompiling it on that computer. I am a beginner so bare answering this question.:)
Thanks
There are a few parts to your problem.
1) You need to compile it for each architecture you want it to be used on.
2) Each architecture will have a set of Qt dynamic libraries associated with it too that need to be available.
3) Some architectures have an easy-to-deploy mechanism. EG, on a mac you can run "macdeployqt" to get the libraries into the application directory. For nokia phones (symbian, harmattan (N9), etc) QtCreator has a deploy step that will build a package for the phone and even include an icon.
4) For systems without such a feature, like linux and windows, you'll either need to distribute the binary and require the user to have Qt available or to package up a directory/zip containing the needed Qt libraries and distribute that.
It doesn't launch because it cannot find the dependencies. As you are on Windows, these libraries can be moved in the same directory as your application. To find which library is missing, use dependency walker
I am pretty sure these libraries are not found:
The Qt dynamic libraries (can be found on Qt bin directory, take the dll)
The C dynamic libraries used for compilation. If you are on creator and use default setting it will be mingw-xxx(can be found in the Qt installation directory, don t know exactly where)
Every Architect has a set of CPU Instructions.
so it's like when you hear a language that you don't understand. like when i speak Arabic To Someone who don't Understand The Language.
Every Architect Has a set of Processor Instructions, The Compiler only convert the code into instruction only understood by The Architecture that your CPU is.
That's Why Python and the most of High level languages Use Interpreter Instead of a Compiler.
But There are some cross compilers like MinGw that Support Cross compiling To Windows (.exe files)
Simply QT Have some libraries important to be in the working directory for your project.