I've installed GPS GPS 6.1.1 (20150118) hosted on i686-pc-mingw32 GNAT GPL 2015 (20150428-49).
It successfully compiles Hello World, but even release executable is huge since it includes statically compiled not-optimized runtime and (what is more important) as far as I understand ada runtime is licensed under GPL and can not be statically linked into closed-source executable.
How can I configure GPS / gcc to link runtime dynamically?
This is very close to this question, and the same answer applies.
However, in case you’d prefer to edit your project properties in GPS via the Project > Properties dialog:
go to the Switches tab (on the left hand side)
go to the Binder tab (at the top)
tick the Shared GNAT run time checkbox.
While you’re there, tick the Store call stack in exceptions checkbox too; this can help debugging an unhandled exception (the binder switch is -E).
I will let someone else answer the specific question, which is (IMO) a good one.
Also good are related questions of minimising the runtime size where the full featured runtime is not necessary, as for "Hello World". Comparing the executable size with the memory installed on your platform, one might conclude this is a case of premature optimization. But for bare-bones executables, e.g. on embedded microcontrollers, it is certainly worth asking.
However there is another implicit question :
How do I divorce my executable from a GPL-encumbered runtime?
and I will answer this.
Historically, the Gnat RTS was not always so encumbered. At one time it featured the "Gnat Modified" GPL, (GMGPL), in which the runtime files contained additional permission above the GPL rights, allowing you to link those components of the RTS with an executable, without burdening your executable with the GPL - effectively allowing you to release such an executable under a closed-source license. (Provided none of its other components were pure GPL).
The Gnat GPL compiler comes with a pure GPL runtime (completely legally) to distinguish it from commercial offerings from the same authors - who have the right to put food on their own table, and their commercial products have an excellent reputation and first class support.
However there is another fork of the older Gnat compiler, offered by the FSF as part of mainstream GCC, which is kept up to date with modern Ada developments including Ada-2012. In some respects it is ahead of Gnat GPL - in the underlying gcc version for example, while in some respects it is behind, as newer Ada features take longer to make it into the FSF branch. But the point here is that it inherited the GMGPL license, and then the very similar "Runtime Exception" in GPLv3. The linked "Rationale and FAQ" should let you determine if this satisfies your needs.
If so. you can compile gcc (including Gnat) from source to meet your needs. This is not a trivial project, however! So for most common platforms, you can find pre-built binaries of the FSF Gnat compiler from the imaginatively named getadanow.com
Disclaimer : I am only pointing out this option. As always with licensing issues, don't take the word of "random guy on the internet" but study the actual licenses of the compiler and RTS you are using and take appropriate legal advice.
Related
When I'm stepping into debugged program, it says that it can't find crt/crt_c.c file. I have sources of gcc 6.3.0 downloaded, but where is crt_c.c in there?
Also how can I find source code for printf and rand in there? I'd like to step through them in debugger.
Ide is codeblocks, if that's important.
Edit: I'm trying to do so because I'm trying to decrease size of my executable. Going straight into freestanding leaves me with a lot of missing functions, so I intend to study and replace them one by one. I'm trying to do that to make my program a little smaller and faster, and to be able to study assembly output a bit easier.
Also, forgot to mention, I'm on windows, msys2. But answer is still helpful.
How can I find source code for printf and rand in there?
They (printf, rand, etc....) are part of your C standard library which (on Linux) is outside of the GCC compiler. But crt0 is provided by GCC (however, is often not compiled with debug information) and some C files there are generated in the build tree during compilation of GCC.
(on Windows, most of the C standard library is proprietary -inside some DLL provided by MicroSoft- and you are probably forbidden to look into the implementation or to reverse-engineer it; AFAIK EU laws might mention some exception related to interoperability¸ but then you need to consult a lawyer and I am not a lawyer)
Look into GNU glibc (or perhaps musl-libc) if you want to study its source code. libc is generally using system calls (listed in syscalls(2)) provided by the Linux kernel.
I'd like to step through them in debugger.
In practice you won't be able to do that easily, because the libc is provided by your distribution and has generally been compiled without debug information in DWARF format.
Some Linux distributions provide a debuggable variant of libc, perhaps as some libc6-dbg package.
(your question lacks motivation and smells like some XY problem)
I intend to study and replace them one by one.
This is very unrealistic (particularly on Windows, whose system call interface is not well documented) and could take you many years (or perhaps more than a lifetime). Do you have that much time?
Read also Operating Systems: Three Easy Pieces and look into OsDev wiki.
I'm trying to do so because I'm trying to decrease size of my executable.
Wrong approach. A debugger needs debug info (e.g. in DWARF) which will increase the size of the executable (but could later be stripped). BTW standard C functions are in some common shared library (or DLL on Windows) which is used by many processes.
I'm on windows, msys2.
Bad choice. Windows is proprietary. Linux is made of free software (more than ten billions lines of source code, if you consider all useful packages inside a typical Linux distribution), whose source code you could study (even if it would take several lifetimes).
I am coding for WinAPI in MinGW
One thing I still have not fully understood is the VC redistributable,
I got a whole pack of question to it
Some say that such programs will need the msvcrt.dll
is the same library needed for bot c++ and c compilation?
is this available on all targets of clients?
must I redistribute it? can I redistribute it?
can I easily get rid of this external dependency?
is there other compiler that will allow me not to carry such unpleasant external dependency? (as I vaguely remember hearing that something is wrong with it - it is probably not core system lib, I heard, or it is not free to use and redistribute the library)
I see something wrong is here as I would like to produce no dependency small exes only calling the system WinAPI and if I use
some like C standard library functions functions I would prefer it economically and statically compiled in, not any third-party dependencies
MSVCRT.DLL contains mostly the C runtime, and MinGW can only use the C part. C++ binary code cannot be used across compilers generally.
It depends on your "target". It is available from Windows 2000.
No. No. It is Microsoft-proprietary code, and every Windows version has a slightly different version.
No. I am not aware of a mature alternative C run-time DLL.
You do not need to worry about the dependency, as it is available everywhere. (Do notice that it is not really a great run-time, esp. regarding multi-byte characters.)
Microsoft compilers can link with "static" libraries so that the resulting executable depends only on system DLLs like kernel32.dll, user32.dll, etc. MinGW cannot do this (yet).
EDIT: A concise description of the MSVCRT.DLL problem is here.
According to the MS White-paper here:
http://www.microsoft.com/en-gb/download/details.aspx?id=13350
you can redistribute certain parts of the Visual Studio components.
Some software, such as the Microsoft .NET Framework, can be
distributed. Components of software products included in MSDN
subscriptions that can be distributed (either within an application or
as separate files) without royalty are identified in the REDIST.TXT
file associated with the product. Components that can be distributed
to non-Microsoft platforms are identified in the OTHER-DIST.TXT file
associated with the product. Code identified as distributable that has
the extension .lib cannot be directly distributed; it must be linked
into the application. However, the resulting output can be
distributed.
You may also:
Modify and distribute source code and objects for code marked as “sample” or “Code Snippet”.
Distribute the unmodified output of Microsoft Merge Modules for use with an application's .msi file.
Distribute the MDAC_TYP.EXE file containing core data access components (such as the Microsoft SQL Server OLE DB provider and ODBC
driver).
Distribute the object version of C++ libraries (Microsoft Foundation Classes, Active Template Libraries, and C runtimes).
MS also produces a redistributable package specifically for the purpose of developers: http://www.microsoft.com/en-gb/download/details.aspx?id=40784
So, to answer your questions:
Yes. Although it is "purely C", it contains fundamental functions that are used by the C++ part of C as well, such as file I/O, time and date functions, math functions, and so on.
Within reason. See link above.
No, yes. As described above: You may choose to just say to customers "you need to download an install this package", but the license should allow you to distribute it free of charge with your product.
Depends on what you call "easily" and exactly what parts of the library your code uses. Some functions may be easy to replace, others not so - but it's not easy in the sense of "yes, just go do http://www.example.com/msvcrt.dll-plugin-replacement" - it would require coming up with some replacement code. The reason MinGW DOESN'T come with its own C library is that it's not entirely trivial to write a replacement for ALL of the windows functionality that you may need here...
See above - if it was easy, someone would have done it. There MAY be some compilers out there that come with their own library, but it's probably not a free-of-charge and free to distribute one (I'm not aware of any product that doesn't rely on the MSVCRT.DLL - but it's not impossible that one exists)
I'm an embedded software engineer working with IA-32 type processors. We are looking for a compiler tool chain - preferable free.
We used to use Mentor Graphics CodeBench Lite but it's no longer available.
We have looked at other GCC distributions but none of them have a bare metal implementation of glibc. None except newlib but we can't use it because of the GPL and LGPL licencing issues. We're an OEM and our customers (and us) have proprietary code.
Any suggestions welcome.
Sourcery's "lite" gpl tools are still available, it's just that Mentor likes to play hide-the-link.
If you want a lightweight C library with non-GPL licensing, you might look at Bionic from Android.
However, you concern may be mistaken. IANAL but most C library licenses have a linking exception of some sort which you may want to research with the help of your lawyers - their utility as system libraries would be extremely limited without.
And actually, a quick search of the newlib licensing page (which is complicated) seems to show that more of it is under BSD-style licenses than under GPL-style ones, though care would be needed to sort it all out.
Mentor may no longer be providing a Lite edition of the IA-32 bare-metal toolchain, but I'm pretty sure it's still supported in the commercial editions, and a basic license is not that expensive.
As Chris says, the Newlib licensing page is a bit complicated -- but the gist of it is that basically all of it that you need for a bare-metal system is BSD licensed; IIRC, the parts that are GPL-licensed are clearly-delineated system-specific pieces that reference things in the Linux kernel or the like (and thus have to be GPL-licensed), and those aren't included in the bare-metal builds. I think they're even all in one or two distinct directories that you can just delete. Obviously you should do the analysis for yourself, but that's the result you should expect to find.
A shortcut that may be useful: The download page for the most recent version of CodeBench Lite for IA-32 ELF that was produced is on this page. If you download the source tarball from there, you'll get the Newlib sources that were used to build that, and there's also a .sh file in the package indicating how it was configured and built. You'll note that in the documentation (licenses are in the back of the Getting Started Guide) the Newlib binaries are simply listed as BSD-licensed, so this should show you how Mentor got a compiled library that fits that licensing description.
(Disclaimer: I used to work for Mentor until recently.)
Reference this question about compiling. I don't understand how my program for Mac can use the right -arch, compile with those -arch flags, the -arch flags be for the system I am on (a ppc64 g5), and still produce the wrong object code.
Also, if I used a cross compiler and was on Linux, produced 10.5 code for mac, how would this be any different than what I described above?
Background is that I have tried to compile various apache modules. They compile with the -arch ppc, ppc64, etc. I get no errors and I get my mod_whatever.so. But, apache will always complain that some symbol isn't found. Apparently, it has to do with what the compiler produces, even though the file type says it is for ppc, ppc64, i386, x_64 (universal binary) and seems to match all the other .so mods I have.
I guess I don't understand how it could compile for my system with no problem and then say my system can't use it. Maybe I do not understand what a compiler is actually giving me.
EDIT: All error messages and the complete process can be seen here.
Thank you.
Looking at the other thread and elsewhere and without a G5 or OSX Server installation, I can only make a few comments and suggestions but perhaps they will help.
It's generally not a good idea to be modifying the o/s vendor's installed software. Installing a new Apache module is less problematic than, say, overwriting an existing library but you're still at the mercy of the vendor in that a Software Update could delete your modifications and, beyond that you have to figure out how the vendor's version was built in the first place. A common practice in the OS X world is to avoid this by making a completely separate installation of an open source product, like Apache, using, for instance, MacPorts. That has its cons, too: to achieve a high-level of independence, MacPorts will often download and build a lot of dependent packages for things which are already in OS X but there's no harm in that other than some extra build cycles and disk space.
That said, it should be possible to build and install apache modules to supplement those supplied by Apple. Apple does publish the changes it makes to open source products here; you can drill down in the various versions there to find the apache directory which contains the source, Makefile and applied patches. That might be of help.
Make sure that the mod_*.so you build are truly 64-bit and don't depend on any non-64 bit libraries. Use otool -L mod_*.so to see the dynamic libraries that each references and then use file on those libraries to ensure they all have ppc64 variants.
Make sure you are using up-to-date developer tools (Xcode 3.1.3 is current).
While the developer tool chain uses many open source components, Apple has enhanced many of them and there are big differences in OS X's ABIs, universal binary support, dynamic libraries, etc. The bottom line is that cross-compilation of OS X-targeted object code on Linux (or any other non-OS X platform) is neither supported nor practical.
Note: I know very little about the GCC toolchain, so this question may not make much sense.
Since GCC includes an Ada front end, and it can emit ARM, and devKitPro is based on GCC, is it possible to use Ada instead of C/C++ for writing code on the DS?
Edit: It seems that the target that devKitARM uses is arm-eabi.
devkitPro is not a toolchain, compiler or indeed any software package. The toolchain used to target the DS is devkitARM, one of the toolchains provided by devkitPro.
It may be possible to build the ada compiler but I doubt very much if you'll ever manage to get anything useful running on the DS itself. devkitPro will certainly never provide an ada compiler as part of the packages we produce.
Yes it is possible, see my project https://github.com/Lucretia/tamp and build the cross compiler as per my script. You would then be able to target NDS using Ada. I have build a basic RTS as well which will provide you with local exception handling.
And #Martin Beckett, why do think Ada is aimed squarely at DoD stuff? They dropped the mandate years ago and Ada is easily usable for any project, you do realise that Ada is a general purpose programming language don't you?
(Disclaimer: I don't know Ada)
Possibly.
You might be able to build devKitPro to use Ada, however, the pre-provided binaries (at least for OS X) do not have Ada support compiled in.
However, you will probably find yourself writing tons of C "glue" code to interface with the various hardware registers and the like.
One thing to consider when porting a language to the nintendo DS is the relatively small stack it has (16KB). There are possible workarounds such as swapping the SRAM stack content into DRAM (4MB) when stack gets full or just have the whole stack in DRAM (assumed to be auwfully slow).
And I second Dre on the fact that you'll have to provide yourself glue between the Ada library function you'd like to use and existing libraries on the DS (which are hopefully covering most of the hardware stuff).
On a practical plane, it is not possible.
On a theoretical plane, you could use one custom Ada parser (I found this one on the ANTLR site, but it is quite old) in order to translate Ada to C/C++, and then feed that to devkitpro.
However, the effort of building such translator is probably going to be equal (if not higher) to creating the game itself.