After looking about for good Fractal generation software I stumbled upon this, and after getting a copy down onto my Windows based PC on which I run Microsoft's Visual Studio 2005 with Python 2.6, I went and ran the setup file with the build argument specified.
Python was happy compiling the main library (gnofract4dc) and I now have a working copy of the .pyd, however, when the extension gnofract4d\_stdlib was being linked, the linker complained of an undefined symbol: gnofract4d\_stdlib. I looked in the main library's code for a function with the same name as the library and found the Python initialization function as expected, but when I looked in the files specified for the \_stdlib library, I could not find a similarly named function. Why is this? and what can I do to define a simple for the linker to detect? Why has such an important function been left out of this Python Compiled Library?
Richard Mant (dx-mon)
I am not exactly sure what problem you're seeing, but to be honest cross-compiling gnofract4d on windows is likely to be a semi-challenging project: it's not pure python but includes some C++ code to go at a decent speed, and that in turn depends on unix libs like pthreads and dl.
If you're a coder and interested in doing a port, that would be awesome - let me know. But the quickest path to cool-looking fractals would be to use a Windows-native program like UltraFractal.
I'm not exactly Cross-Compiling - I'm compiling the C/C++ code for Windows on Windows with the M$ VC++ compiler and linker. (I had noticed that it has Unix based libraries.. I run GnuWin32 versions of them, so those dependencies are satisfied)
I am a programmer (coder as you put it) and I would like to get a fully working version of the C/C++ code for Windows, while also keeping the Linux compilation of it working - something that I have achieved so far using #ifdef's and Python if statements to check whether the platform is Windows or not (sys.platform). If you're interested in my progress to date, then I can upload a tar archive of the project as I've got it on my Windows computer. (I also run Linux in a dual-boot mode which is why I know that the code will still compile on Linux OK)
Is UltraFractal free, btw? (and I'm looking for a Python based generator as I myself am writing a whole load of Python scripts to generate fractals and particularly wanted another Python system so I could see where my Newton-Raphson iteration based fractal is going wrong.)
The low-down of the problem I've hit is after successfully compiling and linking the library called fract4dc , the setup.py script specifies another extension should be built that is called fract4d\_stdlib, the files for this are already compiled thanks to compiling for the *c library, however, linking the *\_stdlib library fails with an error indicating that one symbol defined for export is not defined in any of the object files compiling generated. Looking at the 3 source files reveals that the function (initfract4d\_stdlib) is not defined, unlike the other library's equivalent (initfract4dc) which is. What should I do about that, or is that "error" intended?
You might have better luck trying to compile it using Cygwin (http://www.cygwin.com/) instead of MSVC++. Cygwin provides a Linux compatibility library on top of Windows. It does have a slight performance hit compared to a completely native Windows port, but it makes porting much easier. It also has pygtk2 available as a pre-compiled binary so you don't have to deal with compiling it yourself.
I haven't tried this personally but I don't see any reason it wouldn't work.
hmm.. I've used CygWin before, and from my last experience is: wow does it take up a /lot/ of space! I would use it, but I don't have the disk-space to do so..
As an after-thought to my last posting, perhaps if I define a dummy function to keep the Python compilation happy (the dummy only being included in the Windows version) and make sure the right symbols get exported from the *\_stdlib library, then it'll link.. I've already got GTK+ 2.x on the subject computer as it is used for running The GIMP and Pidgin, both requiring that, so getting pygtk2 into place (if I don't already have it..) will be a fairly easy task I'd have thought.
Ok, after defining a dummy function for the fract4d_stdlib library, that extension now builds, and while I was at it I made sure the library functions were all exported correctly by building a new .cpp file with all the Windows specific stuff in, editing the setup.py to include the new cpp file only if the platform is Windows.
Furthermore, I have persuaded Gnofract4d to boot to the point where it starts trying to compile it's first fractal script, that's my next stumbling block though - getting the compilation process to work, a lot of Python if's are around the corner methinks.
catenary, you suggested I make this a port of the program, I'd more more than willing to make a set of .diff files showing what I've patched and how, so you can introduce the patches into the main source-tree for the program for those on Windows who wish to play with the software when I've finished getting compilation to work. You're call though.
I'd be happy to take patches & would actually like to build & ship an 'official' Windows version - a number of people have asked for it, but I've never quite found the time to do it. So thanks a lot for your work here.
Compilation is an interesting issue since it requires a C compiler to be available on the machine at runtime. No problem on linux, but on Windows I'm not sure what compiler we can reasonably ask Windows users to install.
Ok, well I'll use some space on my own web-server to put patches up for the moment. As for compilers, people can get the VC++ Express Edition of Visual Studio freely, or they can get the Windows version of GCC , I can write some extra routines that locate the compiler on Windows, looking for the Visual Studio on first, and then for GCC so that's not too much of a problem.
address for the diffs (and in the case of the extension modification I made, the full .cpp file): - will load up a directory listing for the moment.)
A complete set of Unified Diff files are now up at the link specified in my last posting, though a word of warning is that the patches are not stable on Windows (they don't affect behaviour on Linux) in that after a successful setup.py build run, running gnofract4d will result in the interface appearing briefly before Python crashes with error "An unknown application error occurred" (0xC0000006 being the assigned error code.. how useful of Microsoft, as usual! )
I am currently looking up what could cause this, and I'm investigating what the Python <-> C++ interface fract4dc is doing exactly to cause such a problem (as the error is being generated somewhere in the extension).
Great, thanks. I won't be able to look at the diffs until the weekend - my day job is a bit hectic right now - but I'll see what I can do with them. That error message probably indicates a null dereference or other unhandled exception. You may be able to run python in the debugger and get an idea of whether the problem is in the extension or the python interpreter itself.
heh, which debugger..? Good thing I've got WinDbg, got a program called Unlocker to unlock the crash dump file the crashes are generating so I can get NotePad++ to open it so I can get a copy, then I'm using WinDbg to read the crash dump back in for the purposes of me looking around what went wrong.. also modified the setup script to make the extensions get compiled with debugging symbols, so I've now located what is causing the error, it most definitely is in the extension fract4dc.. after application of all .diff's, the crash occurs on line 1192 in fract4dmodule.cpp. Now to work out what gets called once the GUI is displayed for that line to become called and why it causes the crash..
I'll probably post again when I've worked out what's happening..
Ok, biased info there.. the particular part of the extension that is crashing is where the fractal is being rendered and there a whole ton of inlined calls here, so I'll have to de-inline them tempararily in order to debug the code..
Call trace as per sofar:
- call in fractFunc.cpp, fractFunc::draw\_all();
- call in fractFunc.cpp, (inline?) fractFunc::draw();
- then somehow call in fract4module.cpp, FDSite::status\_changed();
- call in fract4module.cpp, inline FDSite::send();
- which then directly calls write() which is where the crash happens
I don't have enough time to debug the code quite at the moment.. but I'll work on debugging the extension on Saturday as I should be free then.
Ok, as I've had some free time today, I've been working on the problem some more.. I was wrong to say that fractFunc::draw() was involved, that was a red-herring.. the line above - the call to status_changed() via fractFunct's interface to it - was the one involved.
I've also managed to accurately (hopefully) deduce that this set of crashes are caused by multiple CRT versions trying to access each-other's resources, so line 54 ((self.readfd, self.writefd) = os.pipe()) of gtkfractal.py will need to be wrapped in an if statement (for instance) so that non-Windows platforms continue to use that and then have a function that is conditionally compiled into fract4dc that does the same thing, but for Windows only, so as to bypass multiple CRT versions and just have 1 for each resource and the functions to access said resource.. a messy way to get round it, maybe, but the only sensible way on Windows.
O_o, 4 posts in a row.. oh well..
I've now got gnofract4d running happily, I've fixed a load of bugs to do with the cache not being cleared out correctly on exit, and the program not exiting cleanly. I've also started to look at how to reimplement the input_add() routine in fract4dgui/utils.py, which is currently error'ing every time it is run, (though due to exception handling, it's not causing any crashes) the errors being due to the fact that it is working with GLib IO objects and the inputs to the function are now MSVCRT file descriptors under Windows.
Glad you're making some progress! I'm still trying to get CVS-over-SSH working on Windows - bah.
Not sure the best way to deal with the file descriptor thing. It's all a bit of a hack, originally introduced when I was dealing with Linux distributions which compiled GTK+ without threading support enabled. I've kept it ever since, because it wasn't causing any problems.
See http://gnofract4d.sourceforge.net/manual/internals.html for a brief description of what we're trying to achieve, if you haven't seen it already.
mkay, well with the file descriptor thing, I've already written a Python <-> C++ interface to CreatePipe() to make the pipe ends, and I've been rewriting GLib's Win32 IO Channels into fract4dc so that we don't get more CRT related issues, and I've exposed the functionality via another interface function, fract4dc.io\_add\_watch(). this replaces the io\_add\_watch() call in utils.py . The idea is to fool GLib/GObject into thinking that we're using one of it's interfaces, when we're actually using a compliant one that does the same thing as the internal one, but in our local CRT environment. I then need to rewrite onData() in gtkfractal.py for Windows so that we used fract4dc interfaces to the pipe rather than os.read/write as again, that'll crash out.
I had seen the internals documentation.. thank you. Very useful to know what bit does what, though I noticed that it documents about a fract4dgui component written in C/C++, which is not present in the .tar.gz I downloaded off or the main site originally.
Just uploading my latest modifications to my server.. full implementation of GLib's giowin32.c for fract4dc bundled in win32func.cpp. It seems to crash when a fractal is asked for (I think it's because we're no longer using the GLib implementation of those functions, not sure.. but either way, it crashes.. and I'll debug why in a while.). Proof of concept wise, it works however.
Also included is a new file in fract4dgui which is a Python file acting as an intermediary between either os.read or fract4dc.read (which is a new function I introduced to the C/C++ extension to handle read requests on the pipe created by fract4dc.pipe() so as to prevent the system from crashing with CRT errors again. Windows only function though).
If you already got .diff's down from my server, I'd advise just getting them all again as I'm regenerating them and cannot remember which files I haven't actually modified - modified a large number of them with the latest changes.
I've downloaded the changes and started looking through them.
- I'd also like to try compiling on Windows with the changes. Did you just have Python installed and cl.exe on the path & run setup.py, or something else?
- curious about the CRT mismatch. That just because Python was compiled against a different CRT than the one you're building the extension against? Presumably if it was possible to get them to match this wouldn't be an issue.
- if you're getting fed up with the rather cumbersome forum, feel free to mail catenary at bathysphere dot org
- I have Python 2.6 installed under the standard path for it, it's in my %PATH%, it's built against VC++2008/MSVC90.dll. I have Visual Studio 2005 installed with the directory containing vcvarsall.bat on %PATH%, this then sets up my %PATH% to have cl.exe and link.exe too, that makes anything compiled by me or gnofract4d link against MSVC80.dll or the static version of that (depending on whether /MD or /MT is specified). GLib, and co are all built against MSVCRT.dll which was (under the Microsoft tools) last used as the link library in VC++ 6.0 - a bit archaic.
- I ran "python setup.py build" in the same directory as setup.py/gnofract4d, and then when I had a clean build "python gnofract4d" - need to write some shortcuts to be able to launch gnofract4d without using the command line.
- I'll take you up on the using email instead as it does make life a bit easer.. expect richard at richardmant dot com to be the one I use.
I have now sent you a couple of emails, they contain my latest updates.
The only thing I didn't yet say in them is that the interface now hangs on displaying for some reason or another and I get a load of "Unknown message from fractal thread; " messages printed to the console I'm running Gnofract4d through. Not sure how to proceed..
Ok, sorry for not being very active on this over the last couple of months - had a set of exams last month, and then I only just got enough time to even think about this again now.. 2 things I'm going to do: 1) update my copy of Gnofract4D to fix the Mac OSX bug with darwin, (but have it test for win(32|64) so that the code is future proof) and 2) start the rewrite of the pipe IO code that was proposed for just windows to see if using sockets works, and make a windows specific option so that users on windows can switch between the two methods, with it defaulted to Pipe IO.
No problem at all - I'm happy to get any contributions, at whatever timescale works for you.
I wouldn't worry about a user-selectable option, I don't think many users will care whether they are using pipes or sockets behind the scenes. Concentrate on getting one or the other to work end-to-end.
Gah, my email client is borking up at the moment, so I'll respond to your last email here:
After cleaning up the code-base I'm working from, I've generated a single unified diff for my version against 3.12 so you can preview the changes on that version. I will also generate a new diff for the current Git version a bit later this afternoon.
I will clear out my server's copy of the diff files and new source files which is at http://static.richardmant.com/gnofract4d/ so you can get copies of the Windows-only files needed to make things run. The unified diff file will be up there shortly with the name "gnofract4d.diff"
So I'm just chiming in here, 3 years later, but I was wondering if any progress was made in ever making something to work with Windows? I'd LOVE to be able to use this, as it looks wonderful & I love fractals, but I prefer running Windows because I've used it for almost 20 years and I'm just stuck in my ways, not to mention most programs I need & want are for Windows...otherwise I'd probably just find a Linux distribution to use.... Anyways, I wouldn't mind installing whatever made it possible to make it work (granted there is no spyware or crap in it, but I'm sure that's a given, lol) Anyways, I'd absolutely love to get my hands on this, but I'm just no good when it comes to manually compiling/installing stuff. So my last question is, if there's no chance of me being able to use this on Windows, which distro would be my best chance for using this? I was planning on setting up a dual boot anyways or something like that... or I might just stick with YUMI on a memory stick, but would I be able to run it with any of those? (really sorry if I've just sounded completely stupid, you'll have to forgive me for being only a tiny bit knowledgeable here)
I know for certain that the 4.x and gettext branches compile and run under Windows. Unfortuantely I do not currently have working build VMs which is why no release has been made and I haven't yet found time to rebuild those VMs (I might have some in the next week though).
You are correct that the required packages are virus and crap free - all of the packages are FOSS anyway. Once I know for sure that 64-bit builds work (I know that the 32-bit version works as that was the outcome of my work) I will also write up a NSIS installer to complete the package.
Any Linux distro works with Gnofract4D. YUMI on a memory stick would work just fine. The key things are to ensure you have the libpng and libjpeg development headers and a full GCC (build-essential for Debian) installed. Again, however, I would suggest the 4.x or gettext branches.
Log in to post a comment.