I want to use GprBuild to create a product not licensed under the GPL. Is this possible, and what variant of it and GNAT would I need to use for this to be legal?
I read that in order to make an application not licensed under the GPL with GNAT, I would need to use the FSF distributed version, because that version is released with a linking exception (supposedly; the FSF library directory doesn't actually state that it is licensed under such an exception, but Wikipedia does).
That said, I am struggling to find any similar information for GprBuild. Is it possible that GprBuild doesn't need this exception in order to be used as such? I get the impression that if the latter is true, then it is for a technical reason that I don't fully understand.
The reason why the GCC runtimes need the exception is that the runtimes are included in a delivered product, either as object code or as source (in the case of e.g. the Bison parser generator).
The GCC compiler itself is licensed under pure GPL, because no part of the compiler ends up in the delivered product; and the same applies to tools like gprbuild.
So, FSF compiler/runtime and gprbuild => OK to deliver under proprietary licence.
Related
I have begun to use GTK(2), and I find that the workings of the library to be very good, but the documentation sucks.
I want to upgrade to GTK3, but it seems I need to install something called packman. That is a difficult philosophical step for me. Why can't I simply download a zip file(s) somewhere?
The documentation uses a lot of words without saying much, and the downloads want you to download stuff OTHER then gtk in order to get gtk. Why don't they simply have a GTK package and let me decide if I need all the other stuff.
Also, I have been reading on forums, even if I do the packman stuff, it still isn't enough for C::B.
Anyway, that is mostly a rant, what I'd really like is a suggestion to an alternative to GTK+.
Here are some of my requirements...
#1, It must NOT be an interpreter. Using Code::Blocks and C, I get an exe file and I'd like to continue that way.
#2 It must be programmable using C. I'd really like to stick wiith C::B, but I guess in a pinch I can use Eclipse (although that is another nightmare I won't get into here.)
#3 GTK requires a bunch of DLL's to be shipped along with the exe file. It would be ideal if the entire target could be included in the single exe without having to rely on external dll's or .net framework or other external stuff.
Any suggestions woule be apreaciated.
Thanks, Mark.
You best bet is to give a look at https://en.wikipedia.org/wiki/List_of_widget_toolkits#High-level_widget_toolkits
If you wan to stick to C and not C++, then Qt is out.
The other that stands out is EFL. I've never used it myself, but it has good reputation and probably your best bet if you want to quit GTK+ and stick to C. However I don't know how easy it is to use it on Windows.
Now about GTK+:
Also, I have been reading on forums, even if I do the packman stuff, it still isn't enough for C::B.
There are people here that use GTK+ with Code::Blocks, so I don't get what kind of problem you're referring to.
Then your other problems:
The documentation uses a lot of words without saying much
Examples?
the downloads want you to download stuff OTHER then gtk in order to get gtk
What you don't get is that GTK+ is more that just the libgtk library. It has dependencies on a lot of other libraries, like glib, cairo, pango, etc. In the past there used to be a bundle or installer to have that installed on Windows, but people would mess up on setting the environment up based on their needs and give up. As the GTK+ manpower for the Windows platform is limited, the GTK+ team delegated the distribution of the GTK+ binaries to the MSYS2 project.
MSYS2 is a popular project that provides a lot of open source software already built for Windows, and solves the problem of building and installing dependencies by hand for the user. This step is made to make installation simpler, not harder. In a handful of commands you have GTK+ and all its dependencies installed for your platform, and can start coding your app. Another command and you have python and the python GTK+ bindings installed and can get started. Want to depend on another popular library? Chances are MSYS already provides it.
Windows has been known for decades to be bad on dependency management. If package management wasn't a a pain point on Windows, then stuff like chocolatey or conan wouldn't exist.
Your philosophical reluctance is merely that: philosophical. Sure GTK+ on Windows isn't perfect. With MSYS2 you will get packages built with gcc so the debug symbols are not compatible with the Visual Studio debugger and you will need to use gdb instead. But on your other question you say you use gcc and loathe Visual Studio, so this should not be a blocker to you.
GTK requires a bunch of DLL's to be shipped along with the exe file. It would be ideal if the entire target could be included in the single exe without having to rely on external dll's or .net framework or other external stuff.
This is not possible for the moment as static compilation of GTK+ isn't supported. The redistribution of an app, however, isn't as easy as I'd like it to be. The best way on Windows to redistribute your app while using MSYS2 is to create a pacman package for your app, listing its dependencies, then call pacman to install your app on an empty directory and tell it to install all your dependencies there too. The result will be a directory that you can redistribute, with a self-contained installation of your app and all its dependencies, GTK+ included.
I have been using Coverity Scan for about a year, currently in Windows 7 Pro SP1 x64. Since I first started with it, I had no trouble feeding cov-build my project's make command and it emitting 100% of the compilation units every time. Something has changed with version 8.7.0 of the Coverity Build tool: It takes a similar amount of time to process my source code, but it always results in error and says that no compilation units were emitted.
The intermediate directory has many files written when I use this release of cov-build, and the log has many instances of the following:
error: unknown target triple '--windows-gnu', please use -triple or
-arch WARNING: cov-internal-emit-clang returned with code 4
My source code hasn't changed significantly, I haven't changed any of my build tools either. If I downgrade to the previous version of the build tool (8.5.0.5), it works properly and emits all compilation units as expected. I've emailed Coverity support about this a couple of times, but haven't received a response. Is the latest version of the build tool working for other people?
It turns out that the original 8.7.0 release had a bug that prevented the capture tool from properly identifying the compiler. Coverity support advised me to re-download the 8.7.0 release and it's working normally now.
Looking at the build log snippet you pasted, this looks like you've configured gcc on Windows as comptype clangcc. On MacOSX gcc is really Apple's Clang compiler in disguise, but I'm not aware of the same being true on Windows. This is causing the compiler probes for Clang to fail - most directly indicated by this obviously incorrect compiler version switch:
--comp_ver "gcc.exe (GCC) 4.8.1 Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. "
I believe your solution is to delete your gcc-as-clang configurations and re-run cov-configure. Most likely this will be sufficient:
cov-configure --gcc
however if there is some product bug where that doesn't work (please contact support of that's the case), then this is the more explicit version:
cov-configure --compiler gcc --comptype gcc --template
Did you run cov-configure yourself, or are these the configurations being shipped with SCAN?
My m file was compiled by MATLAB R2008b. When I distributed it to others, their PC seem to lack certain DLL (mclmcrrt79.dll). Thus, I was looking for MCR7.9 but couldn't find any official copy. I did find some on the web: MCR7.9 download but am not sure whether it is safe to be installed. Is it OK to use this copy or is there any official MCR7.9 available?
Since R2012a, the MCR for each version of MATLAB has been available as a download from MathWorks.
Versions of the MCR prior to R2012a are not distributed in the same way by MathWorks, and should be distributed by the developer of the application along with the compiled component directly to end users. If you are the developer, you should distribute it along with the component - specifically, you should send them the MCR installer (you have this - it's in \toolbox\compiler\deploy\<ARCH>, where <ARCH> is your platform).
In fact, in R2012a there was a license-related change: for versions prior to that, you're not actually allowed to make the MCR (or the installer) available as public download (so the people who are making it available at the SourceForge site you link to are, strictly speaking, in breach of the license).
One other confusion may be causing you difficulty: R2008b is MATLAB version 7.7. MATLAB version 7.9 is R2009b. You need to make sure that you use the right version of the MCR for the version of MATLAB you used to compile.
For reference, I solved the problem related to "My Own Exception: Fatal error finding symbol mxCalcSingleSubscript_700 in D:\XYZ\libmx.dll Error:" It was done by sending libmx.dll to the user. The file is stored at \MATLAB\bin\win32\
From my understanding Perl traditionally has only included core functionality, and people install additional libraries to do all sorts of useful (and sometimes very basic) things. But at some point there came to be "core libraries" which are shipped with Perl by default – so you can use these libraries without installing them.
Coming from Python I'm curious how this is managed. Specifically:
How are libraries chosen?
Do the libraries still have their own version numbers and release schedules?
What kind of backward-compatibility guarantees do you have when using these libraries?
Is it common to upgrade or downgrade these libraries in a system? Is this done system-wide or more specifically?
If there's a bug fix that requires an API change, how does that happen?
How is functionality added to these core libraries (if it is at all)?
Currently, only libraries that are necessary to bootstrap/install other libraries go into the core list.
Some are only in the Perl git repository. Some are dual-life on CPAN and in the repo. Sometimes bugs get fixed in the repo and the changes are backported to the CPAN version. Sometimes there's a new release on CPAN and a Perl maintainer checks in the module into the repo.
You can rely on a core module. There's an very lengthy deprecation timespan before one gets removed, recent prominent example was Switch.
Packagers (e.g. the people who build RPMs for a Linux distribution) never could get this right; the wrong order of include paths (#INC) not their fault, and finally fixed with 5.12. This is the reason where the recommendation comes from to compile your own perl and not mess with the system installation. With 5.12, you are supposed to just use CPAN to install an upgraded version of a core module, and it gets installed addtionally to the one shipped with the system, but since the new one comes before the old one in the include path, the new one gets loaded when you use/require it.
Laid out in perlpolicy.
Program the functionality and tests for it, document the thing, then release on CPAN or respectively have a maintainer apply the changeset. This is accompanied with a discussion on p5p.
This is probably a multi-part question. Background: we have a native (c++) library that is part of our application and we have managed to use SWIG to generate a perl wrapper for this library. We'd now like to distribute this perl module as part of our application.
My first question - how should I distribute this module? Is there a standard way to package pre-built perl modules? I know there is ppm for the ActiveState distro, but I also need to distribute this for linux systems. I'm not even sure what files are required to distribute, but I'm guessing it's the pm and so files, at a minimum.
My next question - it looks like I might need to build my module project for each version of perl that I want to support. How do I know which perl versions I should build for? Are there any standard guidelines... or better yet, a way to build a package that will work with multiple versions of perl?
Sorry if my questions make no sense - I'm fairly new to the compiled module aspects of perl.
CLARIFICATION: the underlying compiled source is proprietary (closed source), so I can't just ship source code and the appropriate make artifacts for the package. Wish I could, but it's not going to happen in this case. Thus, I need a sane scheme for packaging prebuilt binary files for my module.
I look after DBD::Informix, one of the Perl Database Driver modules that works with the DBI (Perl Database Interface). The underlying libraries used to connect to IBM Informix Dynamic Server (IDS) are proprietary, but the DBD::Informix code itself is not. I distribute that code on CPAN, just the same as any other Perl module. People can download that source, and (provided that they have the Informix ClientSDK installed on their machine - and Perl and DBI and so on), they can build DBD::Informix to work with their installed Perl.
I would strongly counsel that you arrange that your Perl interface code be made available in source form, even though the library that it interfaces to is proprietary. This allows people to install the code with any version of Perl they have - without requiring you to deal with inconsistencies.
If you still want to provide binary support, you are going to have to work out which platforms you want to support, and build the module with the standard version of Perl on each such platform. This gets messy. You need access to an instance of each machine. Granted, virtual machines make this easier, but it is still fiddly and the number of platforms and versions only grows. But you still need to support people who don't use the standard version of Perl on their machine - that's why the Perl wrapper interface needs to be provided in source form.
DISCLAIMER: I have next to no experience creating binary packages that can easily be installed. Therefore, I am making this post CW to make it easier for others to add their advice.
You should make the distribution available in source form so it can be compiled on each system tailored according to the specifics of that system. I really like Module::Build for that purpose.
For ActiveState users on Windows, you probably want to have four or six PPMs based on whether you want to support 5.6. Package both 32-bit and 64-bit versions for each of 5.6, 5.8 and 5.10. Use the version of mingw you can install using ppm to compile the modules to preserve binary compatibility.
Another option is to use PAR::Packer and distribute your application in a PAR archive. In that context, PAR::WebStart might be useful although I have not tried it. I have had success with PAR archives in the past, though.