I managed to create a .deb file from a source program,tar.gz
how can i create an exe file so that the app can also run on windows?i've searched a lot but didnt manage to find any resources.
If you want to run the program under Windows, you'll need to re-compile it from source using a Windows compiler. How exactly to re-compile it will differ from program to program. Check the program's documentation for details or ask its maintainer. ".deb" files and anything else related to Linux package managers have no meaning in Windows, so you'll need to extract the source from the source .deb or pull it from the appropriate source repository.
Be aware that many Linux programs won't build for Windows with a simple recompile alone. If they use any external libraries, then those libraries need to be available for Windows as well. The Cygwin environment may help here. If there isn't already an official procedure for building that particular program under Windows, then you may have to do the porting work yourself (which is a large enough task that it's well outside the scope of this question).
Related
I was wondering if there was a specific set of library that can decompress tar.gz files in an rtems operating system. Most of the answer I seen is for linux. I was looking at gzip and libz but was not sure if these were for linux or can I use them for rtems as well.
There are some integrated functions that can extract tgz files in RTEMS. Take a look at the tar01 test for some examples with different sources (memory or file): https://git.rtems.org/rtems/tree/testsuites/libtests/tar01/init.c?id=8d989c56ff0c65beb7ec3390aebef6ea52840fab
Note that this is a test application intended to test the functionality. So some things might try to trigger expected failures. The test tar file is automatically generated by the Makefile, translated into some object file and linked into the application.
There is also the tarfs that can use a tar (not sure about tgz) as a read only file system. It's used in tar02 test.
Regarding libz: Although I haven't tried I would expect that it is possible to compile libz for RTEMS. If you need specifically that library you might want to ask on the RTEMS users mailing list whether someone already did that. There are a lot more RTEMS specific users and developers than on stackoverflow.
I am currently looking for ways to expose the location of a shared library on Linux such that it can be picked up easily by any program installed separately. I want to make this location configurable so it can point to different possible installations of the same library. Examples of similar cases I can think of would be Qt5 and Java.
To make a long story short, I am developing FreeRDS, a FreeRDP-based Remote Desktop Services stack. Server-side RDS-aware applications link to libwinpr-wtsapi, a stub library that exposes the Microsoft Windows Terminal Services API interface, but does not implement it. This enables applications to link to libwinpr-wtsapi without having to link directly to a specific RDS implementation. On the first call to any of the WTSAPI functions, the real implementation is loaded dynamically by libwinpr-wtsapi. However, the location of the dynamic library implementing the WTSAPI (here, FreeRDS) needs to be known.
Right now, I am achieving this by setting an environment variable with the full path to the library:
export WTSAPI_LIBRARY=/opt/freerds/lib/x86_64-linux-gnu/libfreerds-fdsapi.so
However, this is not very practical, as this environment variable would need to be set for every program using the WTSAPI. In this case, I have my installation of FreeRDS in /opt/freerds.
I am thinking I could probably simplify this by using a single environment variable to expose the installation prefix of FreeRDS on the system, with something similar to JAVA_HOME:
export FREERDS_HOME=/opt/freerds
However, I then need to know the proper library subdirectory. It is also important to know that it would be possible in the future to offer both a 32-bit and a 64-bit version of the library offering the FreeRDS WTSAPI. This library basically performs RPC with the FreeRDS session manager, so that would be definitely possible.
Let's say we have FREERDS_HOME properly set, or that FreeRDS is installed in the default installation prefix of the system, which files would be "standard" to offer some additional installation configuration information? Here I'm thinking I could have an equivalent of Qt5's qt.conf that would specific installation subdirectories, like the 64-bit installation subdir, the 32-bit installation subdir, etc. However, I don't know where I should be putting that file. Should it be in <prefix>/etc/freerds/freerds.conf?
Ideas, anyone? Thank you!
some (many? all?) Linux distributions today include environment-modules, which aim is exactly to make available many different versions of the same software by customizing the environment (and eventually, shell aliases/functions) with easy front-end commands.
You can find all the needed information here.
Thanks for the multiple answers, here is the solution I finally opted for that satisfies my needs:
As explained earlier, there could be more than one installation of FreeRDS on the same system, but only one of them running at once. We can also assume FreeRDS is supposed to be running before we can attempt to interact with it. Knowing this, I modified FreeRDS to write a simple configuration file in /var/run/freerds.instance with the install prefix and installation subdirectories. This is very similar to having a .pid file, except we're exposing installation paths.
The freerds.instance file is using the .ini format, which is fairly common in configuration files. All that libwinpr-wtsapi has to do is parse /var/run/freerds.instance to find the installation prefix of the current FreeRDS instance, along with the library subdir, so we can find the correct libfreerds-fdsapi.so.
Here is what a sample freerds.instance file looks like:
[FreeRDS]
prefix="/opt/freerds"
bindir="bin"
sbindir="sbin"
libdir="lib/x86_64-linux-gnu"
datarootdir="share"
localstatedir="var"
sysconfdir="etc"
I prefer this solution because it requires literally no special configuration, setting of environment variables, etc. No matter what, we always find the proper FreeRDS installation wherever it is on the system.
You can add a $ORIGIN rpath to your executable, that makes it load libraries relative to the directory the executable is in. (See "ld: Using -rpath,$ORIGIN inside a shared library (recursive)"). This probably applies to dlopen() too.?
$ gcc ... -Wl,-rpath,'$ORIGIN/../lib/dir' -lsomething
I've also found you can run the dynamic linker directly to get some debug facility:
$ /lib/ld-linux.so.2
Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
...
--list list all dependencies and how they are resolved
export LD_LIBRARY_PATH=/yourso.so
i want to compile a 'c' code and create an executable from my application. as of now i do it by specifying the path of my compilation .exe (c++) present in the bin folder of my Dev-Cpp folder.
it works fine but i need to pack the compiler along with the application so i wanted to know what files and folders are needed so that i can compile it directly from the application.
what are the files needed exactly i.e. headers,the compilation application, libs and what else...
any help?
If you're asking how to create and distribute a project which is able to build upon an existing compiler for its functionality, there are packages you can find which are just the compiler portion without the IDE. Minimalist GNU for Windows is such a package:
http://en.wikipedia.org/wiki/MinGW
(In fact, when the people who put together Dev-C++ wrote their integrated development environment, they get the actual compilation functionality from MinGW...which they bundled into their package for good measure. So if you were going to write an IDE of your own, you would start from the MinGW distribution...not by trying to hand-pick files out of Dev-C++.)
One issue to be sensitive to is licensing. While there are not generally any legal issues out of the box regarding distributing executables built with a system like MinGW, when you go as far as to include the compiler in your own "product", it might be tricky. Dev-C++ is under the same license as MinGW (GPL) but I'd imagine there'd be issues if it were not.
If you only need a subset of the full functionality (let's say you only compile C and not C++) there will be a lot of header files and such that you could cut out. But you have to trade off the difficulty of maintaining this sort of optimization vs. just having your program ask users to install MinGW and then tell your program where they installed it. It might take up more space and lead installation to be a two-step process...but frees you from a large number of concerns.
So that's what I would suggest: Have a setting in your program (much like Dev-C++ does) which lets people specify where the MinGW binaries are installed on their system. But let them install it independently.
There is few files with .c anf .h extensions (cmdline.c cmdline.h core.c core.h and so on) in src directory, also there is one file "MakeFile" without extension. Is there any possibility to build these source files into some executable file on Windows 7 (64bits) ? I think i need to download compilers for C or some sdks right?
Yes.
You need to:
download and install a C/C++ compiler (I recommend TDragon's distribution of MinGW ),
add the compiler to your PATH (the installer can do it for you most of the cases); verify it's done by opening cmd.exe and typing gcc -v and mingw32-make -v, both should give you half a screenful of version information if your path is set correctly,
via cmd.exe, navigate to the folder in which the Makefile resides and call mingw32-make.
From now on everything should compile automatically. If it doesn't, post the errors.
Update:
First of all, it'd be useful for you to get the MSys package. Install it and you'll have a more recent version of make (use it instead of mingw32-make from now on).
About the CreateProcess bug, it has to do with the system PATH variable being too long. You'd need to do something like this:
open cmd
execute set PATH=c:/mingw32/bin;c:/msys/1.0/bin (change the paths here to reflect your own installation if it's different)
then as before: navigate to your project's directory, run make. Everything should be smooth now if you're not missing any external libraries.
BTW- remember not to install MinGW or MSys in directories with spaces.
I am not a Windows Developer..
But still as per my knowledge. Visual Studio (i.e 2008, I guess) has the ability to read the Makefile.
Please have a look at it..and if needed change this makefile to their format..
There are many opensource product which are platform independent..and they get compiled on both OS with the just Makefile they provided.
Or else use 'cygwin'
Developer C++ works in windows but it is actually GCC code bought into Windows, Is anyone familiar about the procedure they used to convert the linux ( .sh) to executables ??
I think i need to download compilers for C or some sdks right?
A compiler certainly, but what additional libraries you may need will depend entirely on the code itself. A successful build may also depend on the intended target of the original code and makefile. The makefile may be a GNU makefile, but there are other similar but incompatible make utilities such as Borland Make and MS NMake. If it is a simple build, you may be able to avoid the makefile issue altogether and use the project management provided by an IDE such as Visual C++ 2010 Express.
If you do not know what this code is or what it does and what it needs to build, you are taking a risk building it at all. Maybe you should post a link to the original source so that you can get more specific advice on how to build it.
[EDIT]
Ok, now looking at the code you are attempting to build, it is a very simple build, so if you wanted to avoid using GNU make, then you could just add all the *.c files in the src folder to a project in your IDE and build it.
However there is one serious gotcha, it uses the BSD sockets API and Linux system headers. You will need to first port the code to Windows APIs such as WinSock (very similar to BSD Sockets), or build it under Cygwin (a sledgehammer for a nut somewhat). There may be other Linux dependencies that need sorting, I have not looked in detail, but it looks fairly simple. That said, if you did not have the first clue regarding compiling this stuff, then perhaps this is not a task you could do?
Of course compiling the code may only be half teh problem, if it was designed to run on Linux, there may be run-time dependencies that prevent it running on Windows. Again I have not looked in detail.
Also looking at the code, I would suggest some caution, this may not be the best quality code. That may be unfair, but one obvious flaw and an indication if inexperience is the lack of include guards in the headers.
I have a C code created in Plato3. I want to create an exe file so I can share it with others.
Can someone please tell me how is this possible ?
I have tried sending the exe file that is created when normally compiled, but it crashes every time in runs on computers other than mine ...
Please help,
Thanks :)
[EDIT]
Program running on windows xp or vista .. same error :
Compiler used : SilverFrost (Fortran/C/C++) Development Studio (Plato3)
This application has failed to start
because salflibc.dll was not found,
reinstalling the application may fix
this problem
salflibc.dll is a library installed by the compiler on your development machine.
salf = Salford C Compiler, the obscure compiler included in Silverfrost
libc = C-language runtime support library, necessary for the basic functionality of any program
.dll = dynamically-linked library, i.e. a separate file from your .exe file
You might look for a compiler option that looks like "statically link runtime library;" this might eliminate the DLL dependency. However, if the compiler were capable of doing that, one would expect it to be the default, if not the only way.
However, I recall from the olden days of Classic Mac OS that sometimes DLL runtime libraries were used, the benefit being upgradability. Sometimes is a key word, though. (I suppose when the compiler vendor is the OS vendor, as with MSVC or Apple GCC, it is the norm, though.)
Another trick from that environment was to put the DLL in question in the application's directory and distribute it with the app. Typically runtime DLLs are licensed for free redistribution.
At the very least you have to make sure that the executable is running on the same architecture/operating system that it was compiled on.
Additionally, you need to make sure that any third party, or system libraries that are needed are available on the other systems too.
update
Based on the new information and error message you provide, it looks like you need to re-distribute the salflibc.dll
I would agree with other commenter's and suggest a different platform for development that is more mainstream, or supported.