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.
Related
I have a program written in C that uses dlopen for loading plug-in modules. When the library is dynamically loaded, it runs constructor code which register pointer to structure with function implementations with the main application by use of exported function. I want to use absolute path for specifying the file to dlopen.
Then I have other part of the program with takes file, determine if it is ELF, then looks into the ELF header for specific ELF section, read this section and extract from it pertinent information. This way it filters only shared libraries which I have previously tagged as a plug-in module.
However, I am solving a problem how to discover them on the fly (in portable Linux way, i.e. it will run on Debian and on Fedora too and so on) from the main program. I have been thinking about using ldconfig for this. (As the modules will be installed by way of distro packaging system, APT for example.) Is there any way how to programmatically get the string list of known libraries from C program other than directly reading the /etc/ld.co.cache file? I was thinking that maybe there is some header library which will give char** when I ask.
Or, maybe is there any better solution to my problem?
(I am proponent of using standard system components that programming one-off solutions which will need support in the future.)
Here's my predicament: I am using PhysFS, which allows me to treat multiple directories and archives as one virtual directory. This is for a video game in the future, which I intend to make modder-friendly. PhysFS is the best way to make it modding-friendly.
At the same time, I also intend to use a script-extender of a sort that dnyamically loads libraries and registers them in Lua. I already created a crude, makeshift, largerly proof-of-concept Lua script extender.
So what is my issue? My issue is that dlopen / LoadLibrary only works with files on a real filesystem. And I want to load via PhysFS. I load the file via PHYSFS_openRead, then use PHYSFS_read to load the file's full content into a memory buffer.
Some people suggested loading the .so / .dll file into the memory from PhysFS, and then writing it out to /tmp in Linux, or C:\temp in Windows, and then dlopen-ing it. But I don't think that's a very elegant way to do it.
So... any other ideas? I did look into mmap and thought maybe I could manually load the ELF file (on Linux) and somehow manually extract the functions, and finally register them for Lua, but so far, all I could produce was a program that gave me information about the elf.
People said that I should look into LibJIT, but I'm not exactly sure how that would help me.
So what should I do? How do I load a library into memory via PhysFS, and use an alternative to dlopen to... dlsym the functions out of it?
Please don't suggest dlopen, unless you genuinely suggest that I write out the file temporarily.
My question is largerly: how do I link? How do I get the functions out of the library which I already have in memory? And why do some people suggest LibJIT to me?
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).
I'm a bit naive when it comes to application development in C. I've been writing a lot of code for a programming language I'm working on and I want to include stuff from ICU (for internationalization and unicode support).
The problem is, I'm just not sure if there are any conventions for including a third party library. for something like readline where lots of systems are probably going to have it installed already, it's safe to just link to it (I think). But what about if I wanted to include a version of the library in my own code? Is this common or am I thinking about this all wrong?
If your code requires 3rd party libraries, you need to check for them before you build. On Linux, at least with open-source, the canonical way to do this is to use Autotools to write a configure script that looks for both the presence of libraries and how to use them. Thankfully this is pretty automated and there are tons of examples. Basically you write a configure.ac (and/or a Makefile.am) which are the source files for autoconf and automake respectively. They're transformed into configure and Makefile.in, and ./configure conditionally builds the Makefile with any configure-time options you specify.
Note that this is really only for Linux. I guess the canonical way to do it on Windows is with a project file for an IDE...
If it is a .lib and it has no runtime linked libraries it gets complied into you code. If you need to link to dynamic libraries you will have to assure they are there provide a installer or point the user to where they can obtain them.
If you are talking about shipping your software off to end users and are worried about dependencies - you have to provide them correct packages/installers that include the dependencies needed to run your software, or otherwise make sure the user can get them (subject to local laws, export laws, etc, etc, etc, but that's all about licensing).
You could build your software and statically link in ICU and whatever else you use, or you can ship your software and the ICU shared libraries.
It depends on the OS you're targeting. For Linux and Unix system, you will typically see dynamic linking, so the application will use the library that is already installed on the system. If you do this, that means it's up to the user to obtain the library if they don't already have it. Package managers in Linux will do this for you if you package your application in the distro's package format.
On Windows you typically see static linking, which means the application bundles the library and it will use that specific version. many different applications may use the same library but include their own version. So you can have many copies of the library floating around on your system.
The problem with shipping a copy of the library with your code is that you don't get the benefit of the library's maintainers' bug fixes for free. Obscure, small, and unsupported libraries are generally worth linking statically. Otherwise I'd just add the dependency and ensure that whatever packages you ship indicate it appropriately.
Where can i download the following header files for dev c
sys/types.h
sys/socket.h
netinet/in.h
arpa/inet.h
and also the structure
sockadder and it's derivatives?
I don't know why you need to download these specific files, since they should come with your compiler suite in most modern systems.
You should also keep in mind that they can be radically different depending on your platform and that those files often #include other non-standard files (which #include others and so on). This could make those files very hard to parse and understand.
That said, from some indeterminate version of Linux:
http://linux.die.net/include/sys/types.h
http://linux.die.net/include/sys/socket.h
http://linux.die.net/include/netinet/in.h
http://linux.die.net/include/arpa/inet.h
If you are going to replace missing files, consider getting/reinstalling a proper compiler suite and any developer packages your are missing.
If you want to look at the structure definitions you should definitely be looking at the documentation rather than the actual implementations. That way you avoid tying your code to private definitions e.t.c. that can change between systems.
EDIT:
Just to confirm some of my comments above, struct sockaddr for said version of Linux is defined piece-by-piece in:
http://linux.die.net/include/bits/socket.h
http://linux.die.net/include/bits/sockaddr.h
What SDK are you working with? For Linux you get these files as part of your core C sdk. For Windows it comes with the SDK as well. If you just want a quick and dirty look at some header files I use http://www.google.com/codesearch.
Those headers (not header files) are part of the implementation. They need not be real files.
If your implementation does not provide them, you're out of luck.
If your implementation provides them as real files and you deleted them, reinstalling the compiler might work.
If your implementation provides them as real files and you cannot reinstall the compiler your approach might work. Sorry, I have no idea where to download the files --- or why would anyone copy the files somewhere in the first place.
I'm assuming that you are trying to compile a source code for the *nix platform under another, such as Windows. This approach won't do you any good. Remember that you'll need the libraries of those headers and they are not portable.
Install a Virtual Machine with Ubuntu on your PC to do this kind of development.
do:
apt-get install gcc-4.2