Hi all. Just thought I'd update everyone on the Win32 situation.
Re: win32 startup crashes =================== For the entire summer, I have been without a Win32 box on which to do native builds or test Inkscape. All I can do is make cross-compiled builds and depend on other people to test and debug Win32 factors.
Simarilius and others have been researching many possible reasons for the crashing bugs, and trying to alleviate them. malloc/free and null pointers seem to be prime suspects.
One possibility occurred to me yesterday. The GCC3.4.1 compiler we have been using for cross-compiling was a CVS HEAD version, and not the final 3.4.1 release. It was possible that MinGW patches might insufficiently apply to this code. It is thus possible that the objects created from C++ might be buggy.
So I rebuilt the cross-compiler and all of the C++ libs in our gtk24.zip collection, and put these new builds on the web site. Anyone building Win32 Inkscape should get a fresh copy of these. The same links as before have the new items.
I built Inkscape with these libs yesterday, put them on the server. Bulia said it works; Simarilius says there are still some problems.
So -at least- we are making some progress.
One possible problem area to investigate is MSVCRT's RtlFreeHeap() seeing different address spaces in the .exe and .dlls. Allocating memory in one, and freeing in the other would cause a fault in WinNT and above (not 9x).
Re: server =================== After more than a week of downtime, my little development server is partially back online. The current location is now: http://troi.hous.es3.titan.com/~rjamison/inkscape
By 'partially,' I mean that it can be accessed via http, but the admin has not fixed the routers to allow the machine to see the Net. So it cannot do a cvs checkout, thus cannot do an autobuild. The admin is a good guy, so this condition is certainly temporary.
Because of this, I did a manual build, and put a copy in the /builds subfolder (link at the top of the page). I will do this occasionally until things are fixed. InkscapeLatest.zip points to it.
Bob
Bob Jamison wrote:
Hi all. Just thought I'd update everyone on the Win32 situation.
Re: win32 startup crashes
..........
So I rebuilt the cross-compiler and all of the C++ libs in our gtk24.zip collection, and put these new builds on the web site. Anyone building Win32 Inkscape should get a fresh copy of these. The same links as before have the new items.
I built Inkscape with these libs yesterday, put them on the server. Bulia said it works; Simarilius says there are still some problems.
FYI, the X-compiled build from the web site did not work for me (W2K). Thanks for your efforts / instructions on your website, I decided to try and build on W2K natively. I have managed to get a build which atleast starts (as opposed to crashing on startup). Main thing I notice is that none of the text items are visible / are getting created.
I found the following:
1) The link to gtk libraries zip is wrong. It should be pointing to gtk24.zip (windows section of instructions).
2) Additionally, I modified the GTK variable in mingwenv.bat also. Do not know if that is necessary.
3) First time around, the line $(RM) libinkscape.a (in Makefile.mingw of inkscape/src) causes issues. I commented it out first time.
4) I had some issues with spaces in paths. Issues with g++ and tmp folder resolved by making sure TMP is set to a path that does not contain blank spaces.
5) In the inkscape/Makefile.mingw there is the line
<TAB># $(CP) $(GTKDOS)$(S)bin$(S)libiconv-2.dll inkscape
Tabs are not allowed there. So, I just deleted the line
6) iconv.dll was missing from the gtk24.zip. I copied the one from gtk2.zip into the right place. Required by $(CP) $(GTKDOS)$(S)bin$(S)iconv.dll inkscape in inkscape/Makefile.mingw
7) In inkscape/src/Makefile.mingw I had to change the targets: inkspace.exe and inkview.exe to use "libinkscape.a" instead of "libinkscapedll.a"
8) In file Makefile.mingw.common I had to add
-LC:/MinGW/lib and -lstdc++ to fix the problem of "reference to `__gxx_personality_v0'" when doing the dllwrap.
9) I had to comment out a line related to POV to get it to compile.
BTW, if not for your instructions I would never have attempted this. Maybe someone would volunteer to fix the instructions and the make files etc.
Thanks. Sudhan -- Eager user
Sudhan wrote:
FYI, the X-compiled build from the web site did not work for me (W2K).
We have had reports that it works on Win9x, and not NT and above, so this at least seems consistent! ;-) Predictability has its own virtue.
Thanks for your efforts / instructions on your website, I decided to try and build on W2K natively. I have managed to get a build which atleast starts (as opposed to crashing on startup). Main thing I notice is that none of the text items are visible / are getting created.
I found the following:
- The link to gtk libraries zip is wrong. It should be pointing to
gtk24.zip (windows section of instructions).
You are absolutely right. This is left over from Inkscape 0.39.
- Additionally, I modified the GTK variable in mingwenv.bat also. Do
not know if that is necessary.
This will be different on everyone's box. Change this to whatever you need. The path I have in that file is more of a suggestion than a mandate.
- First time around, the line
$(RM) libinkscape.a (in Makefile.mingw of inkscape/src) causes issues. I commented it out first time.
Thanks. Since I am not on a windows box, I get these wrong sometimes. Makefile.mingw.common should have the definition of RM. Would 'del /y' work both on w9x command.com and NT+ cmd.exe?
- I had some issues with spaces in paths. Issues with g++ and tmp
folder resolved by making sure TMP is set to a path that does not contain blank spaces.
Yes, this should be in the instructions. This is something that never occurs to me, as I would -never- allow spaces in a file name. No spaces!!
- In the inkscape/Makefile.mingw there is the line
<TAB># $(CP) $(GTKDOS)$(S)bin$(S)libiconv-2.dll inkscape
Tabs are not allowed there. So, I just deleted the line
- iconv.dll was missing from the gtk24.zip. I copied the one from
gtk2.zip into the right place. Required by $(CP) $(GTKDOS)$(S)bin$(S)iconv.dll inkscape in inkscape/Makefile.mingw
We should not need both. I will look at what is needed.
- In inkscape/src/Makefile.mingw I had to change the targets:
inkspace.exe and inkview.exe to use "libinkscape.a" instead of "libinkscapedll.a"
We -WANT- the DLL, so that we can package Inkscape and Inkview and whatever executables we deliver, without the distro size becoming huge. This just needs to be worked out. However, for testing, maybe we can add an alternate target, "inkscape-static".
- In file Makefile.mingw.common I had to add
-LC:/MinGW/lib and -lstdc++ to fix the problem of "reference to `__gxx_personality_v0'" when doing the dllwrap.
-lstdc++ should definitely be in there. I'll check this.
- I had to comment out a line related to POV to get it to compile.
This was added just last night to the autoconf/automake tree. Occasionally 'perl mkfiles.pl' and 'perl mkdep.pl' need to be run in the Win32 build, to sync it up with the Gnu Autotools. I guess that I need to add this to the instructions. We will also need to tell the user to download ActivePerl, to run these perl files, same as the makedef.pl for the DLL.
BTW, if not for your instructions I would never have attempted this. Maybe someone would volunteer to fix the instructions and the make files etc.
Thanks. Sudhan -- Eager user
Thanks for the information. We are in the midst of fixing the some of these problems, so any information is valuable to us.
Bob
--- Bob Jamison <rjamison@...357...> wrote:
Sudhan wrote:
FYI, the X-compiled build from the web site did not work for me
(W2K).
We have had reports that it works on Win9x, and not NT and above, so this at least seems consistent! ;-) Predictability has its own virtue.
Thanks for your efforts / instructions on your website, I decided
to
try and build on W2K natively. I have managed to get a build which atleast starts (as opposed to crashing on startup). Main thing I notice is that none of the text items are visible / are getting
created.
Getting better results on 2k than me then, the only way I can get it to start is to launch it through gdb, then gt gdb to ignore all the sigtrap signals being generated.
- First time around, the line
$(RM) libinkscape.a (in Makefile.mingw of inkscape/src) causes issues. I commented it out first time.
Thanks. Since I am not on a windows box, I get these wrong sometimes. Makefile.mingw.common should have the definition of RM. Would 'del /y' work both on w9x command.com and NT+ cmd.exe?
The issue is libinkscape.a not existing the first time you build, and hence not being able to be deleted. I just put a - in front of that line, so it trys but carrys on even if it fails.
BTW, if not for your instructions I would never have attempted
this.
same here, decent windows build instructions/makefiles was the reason I chose IS over sodipodi when I was first looking for a SVG editor.
John
__________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail
Bob Jamison wrote:
We -WANT- the DLL, so that we can package Inkscape and Inkview and whatever executables we deliver, without the distro size becoming huge. This just needs to be worked out. However, for testing, maybe we can add an alternate target, "inkscape-static".
Actually, after pondering this, why don't we temporarily go back to the "old way" and link statically and not strip, the way we did in 0.39(-) ? This DLL, though it will be needed eventually, is becoming something of a burden, and is stealing time from development. Let's have the DLL be a low priority item, and get back to coding.
This build: http://troi.hous.es3.titan.com/~rjamison/inkscape/builds/Inkscape0408270845....
is statically linked and unstripped, just like we are accustomed. Please try it and let me know if it works.
Bob
Bob Jamison wrote:
Bob Jamison wrote:
We -WANT- the DLL, so that we can package Inkscape and Inkview and whatever executables we deliver, without the distro size becoming huge. This just needs to be worked out. However, for testing, maybe we can add an alternate target, "inkscape-static".
Actually, after pondering this, why don't we temporarily go back to the "old way" and link statically and not strip, the way we did in 0.39(-) ? This DLL, though it will be needed eventually, is becoming something of a burden, and is stealing time from development. Let's have the DLL be a low priority item, and get back to coding.
This build: http://troi.hous.es3.titan.com/~rjamison/inkscape/builds/Inkscape0408270845....
is statically linked and unstripped, just like we are accustomed. Please try it and let me know if it works.
Nope. Doesn't work. Crashes when starting up. DrWatson Log indicates Access Violation like it used to before.
Meanwhile, I checked out files after the 'code freeze' and managed to successfully build and run inkscape, but the issues with the text elements still cannot be created/viewed (Pango problems?)
Sudhan
participants (3)
-
Bob Jamison -
John Cliff -
Sudhan