I know the answer might be negative, but is there any way to run Gnss-Sdr on Windows Instead of Linux/Mac OS?
I Use it on Linux Already But I have just wondered if it can be done.
only related answers please.
It's possible. I'm just doing this. The problem is that some code fragments are written under Linux. The build system and library search methods are also under it. For the first time, I had to cut TCP data transfer and heavily correct some CMake files. I build it with the help MSYS2 under MinGW. The biggest problem is linking files. At this stage, I build most of the individual components. It was also required to manually build all the libraries. With my little experience in porting programs from system to system, it was hard
I am interested in how the binary utilities of Linux are coded and how do they work. Where can I find the source code for them?
Strings is usually part of the binutils and since they are maintained by the Free Software Foundation and licensed under the GNU Public License, the source code is available here:
http://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git
or packages of version related snapshots here:
ftp://sourceware.org/pub/binutils/snapshots
If you want to start with a general overview, try the Wikipedia page for binutils or this explanation of the toolchain (more a general description)
I wonder if we can a reduce just a little bit the effort around packages
under linux/unix OS environments and software installations.
It is my stance that there is too much redundant effort about $subject.
I have been pondering about ways to connect build systems of $subject
with some next "stage build tools", like: easybuild (1) & openbuildservice (2);
read below for more details.
To be more specific, I was able last week to take pkgsrc's repository,
process the Makefiles via a tiny "pkg2eb" script and produce *.eb files
for easybuild, then fed many parallel gcc compilations with them.
That "blindly-driven process" ended up in >600 successful builds,
ie. these were packages that simply needed 'wget/configure/make/make install';
It's not bad for a first run, just wonder if it can be done any better.
So:
According to your experience, which OS has the cleanest/leanest
pkgsrc/port structure to be sourced & fed to other external tools?
This is NOT the same as which has the most available packages!
Have you heard of any similar efforts trying to massively produce
packages from eg. a common source list in a structured manner?
(I mean, in a transferable way across different build systems)
So,
much relevant information is visible here:
http://www.mancoosi.org/edos/packages/ # lengthy description of various packaging formats
this one shows the higher level picture:
http://www.mancoosi.org/edos/suggestions/ (esp. 2.1.1 Expressivity shortcomings)
Anyway, to answer to original question, the best bets as of now are:
RPM's .spec files
DEB control files
pkgsrc; possible but some hackery is still needed
portage; quite clean, distinguishes between DEPEND and RDEPEND
macports; easy to parse; very detailed dependencies aspects
ports; like pkgsrc; multiple dependencies defined
I was reading an article about cross-compiling for OSX on linux, but it was quite hard to understand.
What tools do I need? And what configurations are necessary?
Are there any tools for creating packages too?
First you need odcctools, which contains assembler and linker and such (like binutils but capable of handling the Mach-O object format). Then you need the system libraries from the official SDK. You can download it from Apple, but must agree to some stuff and become a member to do so. And finally good old gcc. Quite easy in theory, but in reallity a horrible mess. The easiest way to go (that I know of) is to use I'm Cross!.
Update: I found a newer and better updated method called xchain. It requires more manual work than I'm Cross! thou.
I want to be able to distribute a program in Linux without distributing the source with it. The current solution is distributing a tar.gz with a precompiled binary. What is the easiest way to have this binary be placed in the Applications Menu? Is there a way to do this that is common across most linux distributions, but Ubuntu, Fedora, and OpenSUSE would be the priority.
You will want to create a .deb and a .rpm. The former covers Ubuntu (Debian variants), and the latter Red Hat variants. You can also supply a standalone executable for other users who can deal with things like menus themselves.
You will have to deal with Gnome and KDE menu management, and also different distributions lay out their menus differently. There is also the issue of netbook variants such as Moblin, that have a netbook interface that probably has its own "add application" mechanism. I don't know if it is possible for a single .deb to handle both Gnome and KDE menus systems (for Ubuntu and Kubuntu respectively) but I imagine the capability is there to reduce duplication of effort for Ubuntu.
All recent distributions should have xdg-utils installed, which provides scripts such as
xdg-desktop-icon
xdg-desktop-menu
which seem to be what you're looking for.
Haven't looked into it lately...but back in the day (which really wasn't all that long ago) when I was using Linux, RPM was the easiest way to distribute pre-combiled binaries (most distributations had, and still have, some kind of support for RPM packages).
Here's an old how-to on building an RPM package:
Linux Online - RPM How-To
You could look at BitRock intaller.
Try Autopackage or other solutions posted in another question.
Do tar.gz and then give community rights to redistribute modified packages. They will make RPMs, DEBs and any other packages for their beloved distributions... which will probably fit their distros much better than you could ever make.
There is really too many differences between distributions to make one-size-fits-all package, often subtle ones. For example some distributions has "Application" section, other "Applications"... and this made menu items disappear on some distros. Libraries can be different, default settings can be different, and so on...
RPMs and DEBs aren't so portable as it is believed. With one package there might be problems even with different versions of a single distribution, and there is nothing worse than fighting to install badly prepared package correctly.
JeeBee is correct that you would want to go with .deb or .rpm.
For Ubuntu/Debian (the .deb) I would add that you do not send it to people but you create a "repository" and have the users add that url to their /etc/apt/sources.list, then you get a easy way to update the software as well.
That way you solve the distribution and updated problem at the same time.
And here is a example of how this could look like:
http://www.avrfreaks.net/wiki/index.php/Documentation:AVR32_General/Installing_tools_on_Ubuntu_Linux#Ubuntu_8.04_-_Hardy_Heron
And how a repository could look like:
http://www.atmel.no/avr32/ubuntu/
But don't repeat Atmels mistake and only do i386 because there is a lot of other common architectures out there right now, like the amd64.
/Johan
For RPM, this three-part tutorial by IBM is the best beginner's guide to packaging I know:
http://www.ibm.com/developerworks/library/l-rpm1/
http://www.ibm.com/developerworks/library/l-rpm2/
http://www.ibm.com/developerworks/library/l-rpm3.html