Here's the situation :
I have written a small node application on Windows. This application requires a few non-core node modules such as 'ffi' and 'express'. I have installed those with npm and everything works fine.
Now I want to port this application on an embedded build root linux distribution, which has no compiler nor internet access.
At first, as js is interpreted, I thought just copying the modules would do but I got 'invalid ELF header' errors so it seems those modules require compilation and are thus OS dependent.
Issue :
So I would like to generate those modules for this embedded linux distribution from my Windows machine.
I allready have the cross-compiler, as I use it for my main application on this embedded linux (via cmake and eclipse).
--> How can I generate those modules ?
Do I need is to generate a makefile which targets the right OS ? If so, how ?
Or do I need to use gyp ? If so, how ?
Is there another way ?
(If absolutely necessary, I could use a linux in a virtual machine but this would make it much heavier and I'd still need cross compilation so this is the last resort).
I am a C/C++ Windows developper. I have little to no experience with Node, js and linux so please be explicit in your answers.
Thank you very much.
For information, it appears it's not possible, we've had to abandon this method and do something else.
Related
I have an Ubuntu server (with a VPN and a samba share), where I store all my project files and so on.
I would like not to have to back up the files I have on my computer to the server, but instead, directly use the files that are on the server.
But, when I want to build a project on Windows, it gets really slow, since I basically have to be transferring that whole bunch of files visual studio creates through the internet, so I can build the project.
The core concept is:
Open files that are on the server and use them (ie. saving one file at a time is fast enough not to make a difference).
Compile the code on Linux (Maybe code a VS extension with sockets that will tell the server to build, and that server-side, when done building, will send a message back, for VS to run and debug the program). Which would be much better since my laptop is nothing compared to the server performance-wise.
Run and debug the program with VS on windows.
I've so far only been able to find this(which is not what I want because it uses g++, and I'd like VC++) and this(which is not what I want because it's compiling for linux and executing it remotely). What I'm looking for is a mixture of both.
Remote compiling, local programming and executing.
Would also be great because supposedly, I could build with whatever VC++ version I wanted with whatever SDK I wanted. So I could basically easily switch between compiling for Windows 7 and 10.
I'd just like to know: Is it possible to achieve that? And if so how?
Using VC++ directly on Linux is not possible.
To let the Linux server do the compiling with VC++ anyway you could either use wine which apparently works with older Versions (see https://appdb.winehq.org/objectManager.php?sClass=application&iId=5766
) but propably is not easy to set up in a CLI envrioment and might cause License Issues with Microsoft, or use Windows Virtual Machines, which tend to have some Performance drawback.
The best Solution would be to use GCC (g++), which works on a wide range of architectures and operating systems and supports cross compiling.
I'm currently working on a Linux project. This project needs to run under every Linux distribution (without installing any package/libraries/others for the clients) and it's a bit hard to do it well.
I already tried to do it myself, see this, i have also tried to use CDE but it didn't work well since i got an error with some distribution. For example:
Ubuntu 8.04: Impossible to read the header ELF
Debian 7.8: version of GLIBC_2.14 not found
So, i would like to know if there is a way to get a package of my program who can run under every Linux distribution.
Thanks
Edit: I would like to avoid the static compilation, since my program is pretty big.
There are big differences between linux distributions, especially version of libraries and package management system.
The only way how to do it is to build/compile your project against all libraries you need to use statically, and distribute them with your project.
For example skype and ejabberd do it this way.
I have developed a small application in Qt Creator on Ubuntu 12.04 which I want should run on any other linux distro (mostly different versions of CentOS and ubuntu), just like any portable application on windows does.
I want to be able to simply share the binary file of the Application, and run the application.
I am able to successfully do this in windows, by just building the project in QT Creator and then putting the required libraries in the Application directory and then transfering them to other windows systems.
I searched all over and found out that I should be trying to build the project using LSB(Linux Standard Base) Compatibility, so that it runs on other linux distros. Is that the right way to do this?
I am very new to Qt and also to Linux (dont know much of Shell Scripting).
Thus, I dont know how I should proceed to make the Application LSB Compliant.
I have refered to, the following links:
Distributing Qt-based binaries on Linux and
Deploying Qt applications on Linux but have not beem able to understand what I am suposed to do.
I also found this question here which states a very similar situation as mine, but because I am a novice, I dont know how I should do this.
Moreover, considering that the first two articles were written 6 years back, shouldn't there be a simpler way to deploy Qt apps on the linux platform now?
I also saw something about static linking, is that the way to go?
Isn't there a way by which all of this can be done through Qt Creator itself?
If there is no hope of creating a portable Qt Application for Linux, then is there a way, say a shell script or something that would combine all the steps required to compile the Qt project on another computer and run it. Say, download Qt-SDK if not present, run qmake and make and then the newly compiled application, if not already there, so that the user can run the program just by running one script.
Your problem here is not the Linux Standard Base, but rather the presence or not of the specific version of Qt you need (or a later one).
Exactly like on a Windows machine, a user may have any of Qt installed, or they may not have it at all. On Windows it is easier to check for the presence of a certain version of Qt than it is on Linux, thus it is easier to write install tools that automate the experience.
To solve your problem there are a few ways:
Inform the user that your program requires a certain version of Qt or higher, and let the user handle the problem
Learn how to create packages for every distribution you want to target and create specific packages
Use a program like 0Install or Elf Statifier to create a package/executable containing all the necessary libraries.
The latter is similar to what many Windows and Mac programs do (they include every library they need within the installer), but it is not the preferred way on Linux, which relies heavily on shared libraries.
Making a binary application compatible with any other Linux distro is practically impossible since you will never know in advance which libraries are available in distro X, or what version of that library is available. Even among a single distro (e.g. Ubuntu), binary application are almost never backward-compatible, since anything built on Ubuntu 12.04 will have dependencies on versions libraries which are installed on that version of Ubuntu, and trying to run that binary on Ubuntu 10.04 will most probably fail simply because it doesn't have a recent enough version of glibc or some other necessary library.
However, the idea can be much more implementable if you limit yourself to a finite list of distros and versions of those distros. You can then know which libraries are available for those distros, and aim for the lowest common denominator. I used to maintain a binary application which had to support several distros (Ubuntu, Fedora, OpenSUSE, SLED, Mandriva), and the way I would do it is install the oldest distro I was targeting on my build machine. That way, the binary application would be linked to the oldest versions of the libraries available on those distros. Unless there's a new major version of such a library (which happens quite rarely, and even then, distros usually distribute the previous major version for a while for compatibility purposes), your compiled binary will then be compatible with all your targeted distros.
Therefore, the quick piece of advice I would give for your situation, use the oldest LTS version of Ubuntu which is still supported (10.04 at the moment) for your development, and you should be pretty safe for most recent popular distros. For the application you already developped on Ubuntu 12.04, you should have no problem simply recompiling the same source on 10.04. Understand that you will never however achieve 100% compatibility with a compiled C++ Qt application.
If Qt is not all that important to you, you could use a higher-level or interpreted language such as Python, Java, Perl or Ruby. With such languages, you can usually count on the language implementation already being installed on the target distro.
Deploy an application in Linux is a nightmare, luckily there are some solutions. Check this projects to build a portable binary with all their dependencies bundled:
http://statifier.sourceforge.net/statifier/main.html
http://www.magicermine.com/index.html
http://www.pgbovine.net/cde.html
Another solution is make a portable 0install package:
http://0install.net/
I recomend this solution. Personally I have been problems with the 3 first packagers.
I was using powervr sdk gles 2 libs in linux in gamekit/ogre for building an application. I get the error
"dlopen tries:libGL.so" after which application crashes.
I tried debugging using DDD etc but couldnt isolate much.
How do I fix this in linux(Ubuntu 10.10)?
Does linux refer to some default in built libs while running dlopen?
A library name like libGL.so is only used for linking at compile time. When run-time linking, you should be using the SONAME; something like libGL.so.1. If that library has any dependencies, they must also be available. Try running 'ldd /path/to/libGL.so.1' and see if there are any missing libraries. Also, make sure that you're pointing to the correct libGL; there could be a few versions on your system, each optimized for different graphics cards.
Is there anyway to write dlls in linux?
Do I have to install windows to write dlls in linux? Right now one of my courses requires me to write a dll for this.
You should take a look into 'shared libraries'
http://www.linux.org/docs/ldp/howto/Program-Library-HOWTO/shared-libraries.html
Lots of folks are getting near the right answer but not providing it: gcc can generate win32 PE/COFF files without problem, and of course can always build as a cross compiler on any platform it can target. The binutils port targets windows .exe and .dll files natively, and there's a "dlltool" utility for handling the edge cases where Unix and Windows linkage metaphors are different.
Additionally, the "mingw32" project provides a set of link libraries and header files for building C applications against the win32 API. These likewise install just fine on any Unix.
Here's a site I turned up after a quick google with instructions for building the toolchain.
Not really. Building any kind of executable intended for OS "A" while using OS "B" is a process commonly known as cross-compilation. In this partciluar case, you would need a cross-compiler running on Linux, but targetting Windows. I don't know any vendor selling such a product.