CLN-list

Download

cln-list@ginac.de

April 2009

4 participants
2 discussions

Re: [CLN-list] msvc support patch
by Bruno Haible 10 May '09

10 May '09

Michael Goffioul wrote: > This link will hopefully clarify this. > > http://www.gnu.org/licenses/gpl-faq.html#WindowsRuntimeAndGPL This FAQ does not make the distinction between whether the installer contains the run-time libraries or not. Based on the verbiage in the GPL (explained in the other mail) I therefore think that this FAQ assumes that the installer does not contain the run-time libraries. > there's no point in discussing the rest. There is, because you or the Octave people have other ways to build an installer that fulfils the letter of the GPL: - Build with an older version of MSVC++, whose runtime libraries are contained in the minimum version of Windows that your package supports, or - Distribute the the MSVC++ runtime libraries in a separate installer (then it's mere "aggregation" in the terms of the GPL), or - Arrange for the installer to pop up a browser window to the Microsoft VC++ redistributables download page. The last two options are still not following the spirit of the GPL (because they encourage the installation of closed-source libraries), but legally not a GPL violation. In the second option, there's also the Microsoft license that you have to look at. I find it funny that the license in the "Microsoft Visual C++ 2008 Redistributables" (vcredist_x86.exe) expressly forbids redistributing its contents. Bruno

2 4

Re: [CLN-list] [GiNaC-list] msvc support patch (Was: use of STL iterators in GiNaC)
by Michael Goffioul 21 Apr '09

21 Apr '09

On Sun, Apr 19, 2009 at 9:53 PM, Richard B. Kreckel <kreckel(a)ginac.de> wrote: > Hi! > > Michael Goffioul wrote: >>> >>> (How) Did you manage to compile CLN with msvc? >> >> Magic. >> >> VC++ per-se is quite (not fully) standard compliant. Most of the >> problems are in the autotool based build framework. With a bit >> of coding, you can make VC++ look like GCC. > > Interesting. Could you write up a summary of what you did and report it on > <cln-list(a)ginac.de>? This way, others will have a chance to pick up on your > work. CLN/GiNaC compilation with VC++ is part of the making of Windows package for octave. All compilation scripts and patches are available under SVN on octave-forge http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/admin/Wi… (run_compilation.sh and libs/) The main problem when compiling packages with VC++ is not the compiler itself, which is pretty C/C++ compliant, but the build toolchain. Most packages in the UNIX world use autoconf/automake/libtool toolchain and those tools do not support VC++ very well (at all). But you can work around that problem by using wrappers around VC++ compiler to make it look like GCC, by translating command flags. You can use such wrappers to build tools equivalent to gcc, g++, ar, ranlib... but based on VC++. You can also provide some missing headers like stdint.h, inttypes.h or unistd.h (you can find some on the web), to further ease porting packages. Once you have those tools, it becomes easier to compile packages using the normal "./configure && make" way, using the MSYS shell. But you still need to take care of some specific issues: 1) libtool: using some post-processing magic, it's possible to make libtool to support VC++ (through the gcc-like wrappers) 2) symbol export: VC++ does not export symbols automatically, so you need to take of it; either by using a .def file (some packages provide their own), or by using dllexport/dllimport qualifiers (again some packages support that as well), or by parsing yourself the object files to generate a .def file automatically (this works well especially for plain C code); of course, when you build a static library (which is what I do or CLN/GiNaC), you don't have to care about that 3) export of data: even with the tricks of point 2), you still need to decorate exported data with dllimport, as VC++ does not have the auto-import feature of MinGW; for packages that do not provide this decoration, you have to write your own patch. For the specific case of CLN, there were a couple of issues I also had to take care of: - struct/class, const/non-const: at some places, CLN foward declares objects as being "class", while there are actually "struct"; VC++ generates different mangled names for struct and class, so you end up with unresolved references. The same happen for const/non-const (forward declare as non-const, but define as const). - assembly code: here I cheated a little bit and used gcc to compile the .S file; this required some hacks in the Makefile - some namespace issues: apparently, declaring a function inside the body of another method, which is parted of the cln namespace, does not make VC++ to tag the declared function with the cln namespace; for instance in number.h, I had to move the "extern" statements of CL_DEFINE_LONG_CONSTRUCTOR out of the method bodies. Bye, Michael.

4 6