Thanks to the helpful hint about btool, I was able to build inkscape on Win32 this morning.
Questions: 1) does anyone know if MinGW 4.0 build from here http://wiki.inkscape.org/wiki/index.php/Win32Port can peacefully coexist with the official MinGW package? I mean is it safe to unzip that MinGW directory right on top of the MingGW 3.4.5 installed by the official package from here: http://sourceforge.net/project/showfiles.php?group_id=2435
My main concern is that the 4.1 package is missing some things I'd like to have like g77 and gdb.
1b) [OT] Ok, what's up with MinGW releases? Why isn't gcc 4.1 available from mingw.org itself?
2) In the version I built, the Selection tool handles come out looking like trashed and/or misaligned memory. Is this a known issue? Both sets of handles (scale and rot/shear) are messed up. All other handles for the other tools seem to be ok. (To repro, hit 'p', draw a curve, hit space.)
3) I can't seem to load any images in my build (like .bmp, .png etc.). [Using the import menu item]
4) "Save window geometry" doesn't. Inkscape always opens up at the same too-small default size whether I have the preference set or not. (That's true for the current release as well as my SVN build). Where would I start looking to go about fixing that?
--bb
On 4/4/07, Bill Baxter <wbaxter@...400...> wrote:
- In the version I built, the Selection tool handles come out looking
like trashed and/or misaligned memory. Is this a known issue? Both sets of handles (scale and rot/shear) are messed up. All other handles for the other tools seem to be ok. (To repro, hit 'p', draw a curve, hit space.)
Is this the case with the builds from http://inkscape.modevia.com/win32/? If not, something's wrong with your build. If yes, something's wrong with your system :) because other users of the builds did not report that.
- I can't seem to load any images in my build (like .bmp, .png etc.).
[Using the import menu item]
Same questions as above
- "Save window geometry" doesn't. Inkscape always opens up at the
same too-small default size whether I have the preference set or not. (That's true for the current release as well as my SVN build). Where would I start looking to go about fixing that?
It saves window geometry _with the document_. Save any document and it will come up the same size when you open it. If you want to affect the size of the new Inkscape window, resave the empty document with the geometry you need as the template (Save As, templates folder in the bookmarks).
On 4/5/07, bulia byak <buliabyak@...400...> wrote:
- "Save window geometry" doesn't. Inkscape always opens up at the
same too-small default size whether I have the preference set or not. (That's true for the current release as well as my SVN build). Where would I start looking to go about fixing that?
It saves window geometry _with the document_. Save any document and it will come up the same size when you open it. If you want to affect the size of the new Inkscape window, resave the empty document with the geometry you need as the template (Save As, templates folder in the bookmarks).
Ok, in that case I think the feature could be improved. In my opinion a) the option in the preferences should be labeled: "Save window geometry with document" b) that perhaps shouldn't even be an option -- just save it all the time (It's a tiny amount of data, isn't it?) c) Regardless of b), there should be a preference for whether or not to _use_ stored geometry values when they are found.
It seems kind of an odd feature, though, since the values are intrinsically user-specific. I think a more logical option would be to save the data in the user's preferences. So instead of embedding it in the file you'd save a list of (file path, geometry) pairs in the user prefs somewhere.
I mean, I can just imagine what would happen now if two artists were collaborating on the same file and one uses a dual monitor setup and the other a laptop. Heck even that even applies to a single user. I use dual monitor at work and a laptop when not at work.
--bb
On 4/5/07, Bill Baxter <wbaxter@...400...> wrote:
Ok, in that case I think the feature could be improved. In my opinion a) the option in the preferences should be labeled: "Save window geometry with document"
It says so in the tooltip - but yes, I agree.
b) that perhaps shouldn't even be an option -- just save it all the time (It's a tiny amount of data, isn't it?) c) Regardless of b), there should be a preference for whether or not to _use_ stored geometry values when they are found.
I think this option actually controls both writing and reading (not sure, need to check out the code)
It seems kind of an odd feature, though, since the values are intrinsically user-specific. I think a more logical option would be to save the data in the user's preferences. So instead of embedding it in the file you'd save a list of (file path, geometry) pairs in the user prefs somewhere.
But then, this information would be lost when you move the file from one identical system to the other. So it's still not ideal. But, perhaps this approach is indeed better overall.
I mean, I can just imagine what would happen now if two artists were collaborating on the same file and one uses a dual monitor setup and the other a laptop. Heck even that even applies to a single user. I use dual monitor at work and a laptop when not at work.
This in fact happens, and we're getting complaints about it.
On 4/5/07, bulia byak <buliabyak@...400...> wrote:
On 4/4/07, Bill Baxter <wbaxter@...400...> wrote:
- In the version I built, the Selection tool handles come out looking
like trashed and/or misaligned memory. Is this a known issue? Both sets of handles (scale and rot/shear) are messed up. All other handles for the other tools seem to be ok. (To repro, hit 'p', draw a curve, hit space.)
Is this the case with the builds from http://inkscape.modevia.com/win32/? If not, something's wrong with your build. If yes, something's wrong with your system :) because other users of the builds did not report that.
- I can't seem to load any images in my build (like .bmp, .png etc.).
[Using the import menu item]
Same questions as above
Ok, that version works. Also if I overwrite the working dev version of inkscape.exe with the one that I built, that works OK too.
I just blew everything away and re-updated from svn, . I'm doing a fresh recompile now.
--bb
On 4/5/07, Bill Baxter <wbaxter@...400...> wrote:
On 4/5/07, bulia byak <buliabyak@...400...> wrote:
On 4/4/07, Bill Baxter <wbaxter@...400...> wrote:
- In the version I built, the Selection tool handles come out looking
like trashed and/or misaligned memory. Is this a known issue? Both sets of handles (scale and rot/shear) are messed up. All other handles for the other tools seem to be ok. (To repro, hit 'p', draw a curve, hit space.)
Is this the case with the builds from http://inkscape.modevia.com/win32/? If not, something's wrong with your build. If yes, something's wrong with your system :) because other users of the builds did not report that.
- I can't seem to load any images in my build (like .bmp, .png etc.).
[Using the import menu item]
Same questions as above
Ok, that version works. Also if I overwrite the working dev version of inkscape.exe with the one that I built, that works OK too.
I just blew everything away and re-updated from svn, . I'm doing a fresh recompile now.
Fresh compile failed.
Looks like this check-in didn't include everything needed?
Revision: 14695 Author: joncruz Date: 9:35:22 AM, Thursday, April 05, 2007 Message: Replacing old multifunction widget with separate widget & model ---- Modified : /inkscape/trunk/src/Makefile_insert Added : /inkscape/trunk/src/ege-select-one-action.cpp Added : /inkscape/trunk/src/ege-select-one-action.h Modified : /inkscape/trunk/src/helper/Makefile_insert Added : /inkscape/trunk/src/helper/unit-tracker.cpp Added : /inkscape/trunk/src/helper/unit-tracker.h Modified : /inkscape/trunk/src/widgets/select-toolbar.cpp
---- Make error line 328: LINK problem: build/libinkscape.a(select-toolbar.o):select-toolbar.cpp:(.text+0x14a): undefined reference to `Inkscape::UnitTracker::~UnitTracker()' build/libinkscape.a(select-toolbar.o):select-toolbar.cpp:(.text+0x2ab): undefined reference to `Inkscape::UnitTracker::addAdjustment(_GtkAdjustment*)' build/libinkscape.a(select-toolbar.o):select-toolbar.cpp:(.text+0x827): undefined reference to `Inkscape::UnitTracker::isUpdating() const' build/libinkscape.a(select-toolbar.o):select-toolbar.cpp:(.text+0x92e): undefined reference to `Inkscape::UnitTracker::getActiveUnit() const' build/libinkscape.a(select-toolbar.o):select-toolbar.cpp:(.text+0x1519): undefined reference to `Inkscape::UnitTracker::getActiveUnit() const' build/libinkscape.a(select-toolbar.o):select-toolbar.cpp:(.text+0x1868): undefined reference to `Inkscape::UnitTracker::setFullVal(_GtkAdjustment*, double)' build/libinkscape.a(select-toolbar.o):select-toolbar.cpp:(.text+0x18d2): undefined reference to `Inkscape::UnitTracker::setFullVal(_GtkAdjustment*, double)' build/libinkscape.a(select-toolbar.o):select-toolbar.cpp:(.text+0x193c): undefined reference to `Inkscape::UnitTracker::setFullVal(_GtkAdjustment*, double)' build/libinkscape.a(select-toolbar.o):select-toolbar.cpp:(.text+0x19a9): undefined reference to `Inkscape::UnitTracker::setFullVal(_GtkAdjustment*, double)' build/libinkscape.a(select-toolbar.o):select-toolbar.cpp:(.text+0x1df5): undefined reference to `Inkscape::UnitTracker::UnitTracker(unsigned int)' build/libinkscape.a(select-toolbar.o):select-toolbar.cpp:(.text+0x1e22): undefined reference to `Inkscape::UnitTracker::addUnit(SPUnitId, int)' build/libinkscape.a(select-toolbar.o):select-toolbar.cpp:(.text+0x1e42): undefined reference to `Inkscape::UnitTracker::setActiveUnit(SPUnit const*)' build/libinkscape.a(select-toolbar.o):select-toolbar.cpp:(.text+0x2285): undefined reference to `Inkscape::UnitTracker::createAction(char const*, char const*, char const*)'
--bb
On Apr 4, 2007, at 9:19 PM, Bill Baxter wrote:
Fresh compile failed.
Looks like this check-in didn't include everything needed?
Revision: 14695 Author: joncruz Date: 9:35:22 AM, Thursday, April 05, 2007 Message: Replacing old multifunction widget with separate widget & model
That commit *should* have included everything. It worked on OS X and on Linux.
UnitTracker is inside of src/helper/unit-tracker.*
On 4/5/07, Jon A. Cruz <jon@...18...> wrote:
Author: joncruz
Date: 9:35:22 AM, Thursday, April 05, 2007
Message:
Replacing old multifunction widget with separate widget & model
That commit *should* have included everything. It worked on OS X and on Linux.
UnitTracker is inside of src/helper/unit-tracker.*
Ok after *another* rebuild it finally built again.
And I figured out the source of my problems with the markers and images. My copy of
GTK\gtk210\etc\gtk-2.0\gdk-pixbuf.loaders
is empty while apparently it should contain about 4k of various stuff relevant to image loading. The reason seems to be that it was empty in the gtk I downloaded from modevia:
http://inkscape.modevia.com/win32libs/gtk210-070402.7z
--bb
Bill Baxter wrote:
On 4/5/07, Jon A. Cruz <jon@...18...> wrote:
Author: joncruz
Date: 9:35:22 AM, Thursday, April 05, 2007
Message:
Replacing old multifunction widget with separate widget & model
That commit *should* have included everything. It worked on OS X and on Linux.
UnitTracker is inside of src/helper/unit-tracker.*
Ok after *another* rebuild it finally built again.
And I figured out the source of my problems with the markers and images. My copy of
GTK\gtk210\etc\gtk-2.0\gdk-pixbuf.loadersis empty while apparently it should contain about 4k of various stuff relevant to image loading. The reason seems to be that it was empty in the gtk I downloaded from modevia:
http://inkscape.modevia.com/win32libs/gtk210-070402.7z
Really? If that is true, then it wouldn't be the first time that I uploaded incomplete .7z's. I'm starting to suspect this latest version of 7-zip that I am using. I'll check.
bob
Jon A. Cruz wrote:
On Apr 4, 2007, at 9:19 PM, Bill Baxter wrote:
Fresh compile failed.
Looks like this check-in didn't include everything needed?
Revision: 14695
Author: joncruz
Date: 9:35:22 AM, Thursday, April 05, 2007
Message:
Replacing old multifunction widget with separate widget & model
That commit *should* have included everything. It worked on OS X and on Linux.
UnitTracker is inside of src/helper/unit-tracker.*
Maybe try deleting build.dep (not build.xml !!! :-) and try again.
bob
Hi,
I was away for a day or so. Sorry I missed this thread.
Bill Baxter wrote:
Thanks to the helpful hint about btool, I was able to build inkscape on Win32 this morning.
I have promised to update that about 10 times or so. I really will, I swear. I have some kind of weird writer's block concerning that file.
Questions:
- does anyone know if MinGW 4.0 build from here http://wiki.inkscape.org/wiki/index.php/Win32Port
can peacefully coexist with the official MinGW package? I mean is it safe to unzip that MinGW directory right on top of the MingGW 3.4.5 installed by the official package from here: http://sourceforge.net/project/showfiles.php?group_id=2435
Basically, no. In addition to the normal rule that the .h's must match the libs, there are also inconsistencies in the C++ .h files. The GCC guys say that you -never- install one on top of the other. You can have problems not only with linking, but also with C++ compiling. This is why G++'s have their C++ dirs versioned. Also, the MinGW guys are in the process of switching from sjlj exceptions (setjump()/longjump()) to Dwarf exception handling (Dwarf EH). Libs made with one exception handling scheme don't mix with the other.
My main concern is that the 4.1 package is missing some things I'd like to have like g77 and gdb.
Building your own gcc was once very difficult, but not anymore. You can make it with MSYS:
tar zxf gcc-4.1.2-whatever.tar.gz cd gcc-4.1.2 mkdir objdir cd objdir ../configure --target=i686-pc-mingw32 --prefix=/mingw --with-sjlj-exceptions \ --enable-languages=c,c++,f77 make make install
....or leave out the languages option to get the defaults.
In msys's etc/fstab file, I have /mingw aliased to c:/mingw
With MSYS, make sure to use their version of make, not the one in MinGW. And you do need that sjlj flag to be compatible with the "official" mingw, and our C++ libs, like gtkmm or libsigc++. I want to switch ours, too, when it is safe.
1b) [OT] Ok, what's up with MinGW releases? Why isn't gcc 4.1 available from mingw.org itself?
Because of the Dwarf EH move, they wanted to wait until gcc-4.x was very stable before moving to that one. You might want to ask Danny Smith (the mingw gcc guy) about that. What is good is the fact that he is now one of the main GCC committers, so mingw is no longer a fringe product but a major subscriber.
- In the version I built, the Selection tool handles come out looking
like trashed and/or misaligned memory. Is this a known issue? Both sets of handles (scale and rot/shear) are messed up. All other handles for the other tools seem to be ok. (To repro, hit 'p', draw a curve, hit space.)
This sounds like either you have mixed Gtk libs, or that maybe you have another installation of gtk in your path.
- I can't seem to load any images in my build (like .bmp, .png etc.).
[Using the import menu item]
Same thing, maybe. GdkPixbuf has image loader modules in its lib directory, and they will silently fail if they can't find the version of libpng.dll, jpeg.dll, tiff.dll, etc, that they want.
- "Save window geometry" doesn't. Inkscape always opens up at the
same too-small default size whether I have the preference set or not. (That's true for the current release as well as my SVN build). Where would I start looking to go about fixing that?
You might try deleting your preferences file from your homedir in /Documents and Settings, and try again.
bob
Bob Jamison wrote:
I have promised to update that about 10 times or so. I really will, I swear. I have some kind of weird writer's block concerning that file.
What if we move the win32 build directions completely into the wiki? Then when you update the build process it can be more of a community project to fix the docs. Sometime it is very difficult for the guy doing it do document the process.
Aaron Spike
On 4/6/07, Aaron Spike <aaron@...749...> wrote:
Bob Jamison wrote:
I have promised to update that about 10 times or so. I really will, I swear. I have some kind of weird writer's block concerning that file.
What if we move the win32 build directions completely into the wiki? Then when you update the build process it can be more of a community project to fix the docs. Sometime it is very difficult for the guy doing it do document the process.
Aaron Spike
Good call. I would have updated the instructions as I was going through the process if it had been a wiki.
--bb
participants (5)
-
Aaron Spike -
Bill Baxter -
Bob Jamison -
bulia byak -
Jon A. Cruz