Trunk r12812 building on Windows for anybody?
There seems to be a build problem right now on Windows with r12812.
bzr update rm build.dep rm -rf build g++ buildtool.cpp -o btool btool
stops here:
compile src/xml/simple-document.cpp compile src/xml/simple-node.cpp compile src/xml/subtree.cpp ##### Target : link ##### link objects and library to create executable --- link / rc --- link / link Make error line 437: LINK problem: mingw32-g++: error: CreateProcess: No such file or directory
Is a new devlib needed? My system is currently at 47. If that is the problem, could we please have a small revision of btool so that it checks the devlib number and emits a useful error message if the needed version is not present?
Thank you,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
Updating devlibs to r50 and subsequently
btool clean btool
solved it for me.
Regards K
mathog schreef op 14/11/2013 0:09:
There seems to be a build problem right now on Windows with r12812.
bzr update rm build.dep rm -rf build g++ buildtool.cpp -o btool btool
stops here:
compile src/xml/simple-document.cpp compile src/xml/simple-node.cpp compile src/xml/subtree.cpp ##### Target : link ##### link objects and library to create executable --- link / rc --- link / link Make error line 437: LINK problem: mingw32-g++: error: CreateProcess: No such file or directory
Is a new devlib needed? My system is currently at 47. If that is the problem, could we please have a small revision of btool so that it checks the devlib number and emits a useful error message if the needed version is not present?
Thank you,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 13-Nov-2013 22:26, Kris De Gussem wrote:
Updating devlibs to r50 and subsequently
btool clean btool
solved it for me.
Not for me though. I hacked btool to capture the problem command, edited it into a single line file, replaced all the \ with /, and then tried to run it this way in Msys:
% . longlink.txt
And it emitted the exact same error message. I thought it might be a command line length issue, since that command is 30152 characters long. Edited it into one clause per line and tried:
mingw32-g++ @longlink3.txt
but that did the same thing too. Tried it with -v on the line and I see why that would not help - it recreated the super long line and tried to pass it to
c:/progs/mingw/bin/../libexec/gcc/mingw32/4.6.2/collect2.exe
Sort of defeats the purpose of @file, eh?
mingw32-g++ does work from the command line to compile and link for short test cases, and obviously it worked up to that point in btool for compile.
Working hypothesis - command line too long. Find redundant clauses and eliminate them, will it link then?
There are a whole bunch of "-Lc:/progs/devlibs50/lib", maybe 40 or 50, reduced that to 1. Then did this again:
mingw32-g++ @longlink3.txt
and it worked.
Conclusion - inkscape is bumping up against a command line length limit in Windows XP, mingw, or Msys. There are some more redundant lines still in that file, but not all that many:
$ wc longlink3.txt 936 936 28665 longlink3.txt $ sort longlink3.txt | uniq | wc 903 903 28305 % grep build longlink3.txt | wc 844 845 27592
Perhaps it is time to consider linking subdirectories of build into their own static libraries, then link all of them together into inkscape?
Either that or I need a different mingw/msys that has a higher command line limit.
I think I need to file a bug on this...
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
The command line length problem has, not surprisingly, bitten other projects before:
http://dev.omnetpp.org/bugs/view.php?id=155
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
I don't have any problem in compiling under Windows XP: yesterday with r12813 and now r12816. Maybe local root paths are relevant: if you start from deeply nested folders your cmd line is inevitably getting too long. I fear there's no solution to this problem other than saying to people not to nest too much their starting folders. If you don't give limits you are going to find someone that exceeds, sooner or later .
-- View this message in context: http://inkscape.13.x6.nabble.com/Trunk-r12812-building-on-Windows-for-anybod... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
On 15-Nov-2013 00:38, LucaDC wrote:
I don't have any problem in compiling under Windows XP: yesterday with r12813 and now r12816. Maybe local root paths are relevant: if you start from deeply nested folders your cmd line is inevitably getting too long.
I don't think the top folder matters much because the huge command line that choked consisted by length almost entirely of addresses relative to it. The only place it showed up was in the -L parameters. For what its worth, the top of mine is:
C:/progs/inkscape_trunk
which doesn't seem excessive.
I fear there's no solution to this problem other than saying to people not to nest too much their starting folders.
Or there is something different about your mingw/msys and mine that lets yours run with longer command lines. On my system this command
g++ --version --version etc.
works when used in "test.sh" or pasted into an msys shell up until a line length of 32744 (including the final \n), but fails for 32754.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
mathog wrote
For what its worth, the top of mine is:
C:/progs/inkscape_trunk
which doesn't seem excessive.
No it isn't, indeed. Mine is longer: "F:\Programmi\Grafica\Inkscape\trunk". But devlibs is under "C:\devlibs" which is very short. Maybe this helps? Next time I'm going to take a look to the log to see how long is the linker command line and let you know.
-- View this message in context: http://inkscape.13.x6.nabble.com/Trunk-r12812-building-on-Windows-for-anybod... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
On 14-11-2013 19:58, mathog wrote:
Conclusion - inkscape is bumping up against a command line length limit in Windows XP, mingw, or Msys. There are some more redundant lines still in that file, but not all that many:
$ wc longlink3.txt 936 936 28665 longlink3.txt $ sort longlink3.txt | uniq | wc 903 903 28305 % grep build longlink3.txt | wc 844 845 27592
Perhaps it is time to consider linking subdirectories of build into their own static libraries, then link all of them together into inkscape?
Thanks for figuring out the problem. The cmdline limit is a pain. I believe we ran into the same problem when trying to set up a build with CMake (and our limit knowledge of how to do that), which created huge cmdlines too.
Not too long ago, we had to switch to linking everything in one go, because we rely on initialization of global namespace objects. See rev. 12559. I don't think this global object init thing is very elegant, and would love to get rid of it. The cmdline limit is a very strong argument of reinstating linking separate static libs.
(I just had the same problem, not in trunk, but while trying to build with updated devlibs, C++11, and Dwarf2-exceptions)
regards, Johan
Relevant thread:
http://sourceforge.net/mailarchive/forum.php?thread_name=CAFLw2WR10-7es%2BYg...
-Johan
Bug filed as https://bugs.launchpad.net/inkscape/+bug/1251405
There is a link there to bug 1227956, which fixed one problem, leading in part to this one.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
2013/11/14 Johan Engelen <jbc.engelen@...2592...>:
Not too long ago, we had to switch to linking everything in one go, because we rely on initialization of global namespace objects. See rev. 12559. I don't think this global object init thing is very elegant, and would love to get rid of it. The cmdline limit is a very strong argument of reinstating linking separate static libs.
To have the cake and eat it too, we should create shared libraries, not static libraries. This will run the global init code but also allow us to modularize. However, building shared libraries with Autotools is very annoying. I'd rather we did this after migrating all platforms to CMake / Waf / something other than Autotools which has native support for shared libs.
Regards, Krzysztof
To have the cake and eat it too, we should create shared libraries, not
static libraries. This will run the global init code but also allow us to modularize. However, building shared libraries with Autotools is very annoying. I'd rather we did this after migrating all platforms to CMake / Waf / something other than Autotools which has native support for shared libs.
Hi, I created a new branch at lp:~engelmarkus/inkscape/cmakebuild for this. Currently it should work in Linux. The dom part and all the lib*-folders are compiled into shared objects. I'm just not sure now where they should be installed to. prefix/lib/inkscape probably? I'll try compilation on Windows and Mac OS later this day. The only thing that's missing currently is the cmake installation "code" for these two platforms.
Regards, Markus
On 16-11-2013 15:54, Markus Engel wrote:
To have the cake and eat it too, we should create shared libraries, not
static libraries. This will run the global init code but also allow us to modularize. However, building shared libraries with Autotools is very annoying. I'd rather we did this after migrating all platforms to CMake / Waf / something other than Autotools which has native support for shared libs.
Hi, I created a new branch at lp:~engelmarkus/inkscape/cmakebuild for this. Currently it should work in Linux. The dom part and all the lib*-folders are compiled into shared objects. I'm just not sure now where they should be installed to. prefix/lib/inkscape probably? I'll try compilation on Windows and Mac OS later this day. The only thing that's missing currently is the cmake installation "code" for these two platforms.
Hi Markus, Open up your branch if you want help!
See the attachment.
Cheers, Johan
On 18-11-2013 20:13, Johan Engelen wrote:
On 16-11-2013 15:54, Markus Engel wrote:
To have the cake and eat it too, we should create shared libraries, not
static libraries. This will run the global init code but also allow us to modularize. However, building shared libraries with Autotools is very annoying. I'd rather we did this after migrating all platforms to CMake / Waf / something other than Autotools which has native support for shared libs.
Hi, I created a new branch at lp:~engelmarkus/inkscape/cmakebuild for this. Currently it should work in Linux. The dom part and all the lib*-folders are compiled into shared objects. I'm just not sure now where they should be installed to. prefix/lib/inkscape probably? I'll try compilation on Windows and Mac OS later this day. The only thing that's missing currently is the cmake installation "code" for these two platforms.
Hi Markus, Open up your branch if you want help!
See the attachment.
The dependency check completes successfully with my patch (previous mail), but linking does not. The commandline for linking does not list any of the dependencies. Output snippet:
FAILED: cmd.exe /c cd . && C:\mingw\bin\c++.exe -shared -o lib/libcola.dll -Wl,--out-implib,lib\libcola.dll.a -Wl,--major-image-version,0,--minor-image-version,0 src/libcola/CMakeFiles/cola.dir/cola.cpp.obj src/libcola/CMakeFiles/cola.dir/conjugate_gradient.cpp.obj src/libcola/CMakeFiles/cola.dir/connected_components.cpp.obj src/libcola/CMakeFiles/cola.dir/gradient_projection.cpp.obj src/libcola/CMakeFiles/cola.dir/shortest_paths.cpp.obj src/libcola/CMakeFiles/cola.dir/straightener.cpp.obj -LD:\inkscape\cmakebuild\inkscape -Lc:\devlibs\lib -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd . Creating library file: lib\libcola.dll.asrc/libcola/CMakeFiles/cola.dir/cola.cpp.obj:cola.cpp:(.text+0x1bd): undefined reference to `vpsc::Rectangle::xBorder'
Cheers, Johan
Actually, I'm not sure why this happens. To me this looks like cmake is behaving differently on linux and on windows/mac. I noticed these missing dependencies in the linking commands, too.
Regards, Markus
-----Ursprüngliche Nachricht----- Von: Johan Engelen [mailto:jbc.engelen@...2592...] Gesendet: Montag, 18. November 2013 20:22 An: Markus Engel Cc: 'inkscape-devel' Betreff: Re: AW: [Inkscape-devel] Trunk r12812 building on Windows for anybody?
On 18-11-2013 20:13, Johan Engelen wrote:
On 16-11-2013 15:54, Markus Engel wrote:
To have the cake and eat it too, we should create shared libraries, not
static libraries. This will run the global init code but also allow us to modularize. However, building shared libraries with Autotools is very annoying. I'd rather we did this after migrating all platforms to CMake / Waf / something other than Autotools which has native support for shared libs.
Hi, I created a new branch at lp:~engelmarkus/inkscape/cmakebuild for this. Currently it should work in Linux. The dom part and all the lib*-folders are compiled into shared objects. I'm just not sure now where they should be installed to. prefix/lib/inkscape probably? I'll try compilation on Windows and Mac OS later this day. The only thing that's missing currently is the cmake installation "code" for these two platforms.
Hi Markus, Open up your branch if you want help!
See the attachment.
The dependency check completes successfully with my patch (previous mail), but linking does not. The commandline for linking does not list any of the dependencies. Output snippet:
FAILED: cmd.exe /c cd . && C:\mingw\bin\c++.exe -shared -o lib/libcola.dll -Wl,--out-implib,lib\libcola.dll.a -Wl,--major-image-version,0,--minor-image-version,0 src/libcola/CMakeFiles/cola.dir/cola.cpp.obj src/libcola/CMakeFiles/cola.dir/conjugate_gradient.cpp.obj src/libcola/CMakeFiles/cola.dir/connected_components.cpp.obj src/libcola/CMakeFiles/cola.dir/gradient_projection.cpp.obj src/libcola/CMakeFiles/cola.dir/shortest_paths.cpp.obj src/libcola/CMakeFiles/cola.dir/straightener.cpp.obj -LD:\inkscape\cmakebuild\inkscape -Lc:\devlibs\lib -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd . Creating library file: lib\libcola.dll.asrc/libcola/CMakeFiles/cola.dir/cola.cpp.obj:cola.cpp:(.tex t+0x1bd): undefined reference to `vpsc::Rectangle::xBorder'
Cheers, Johan
What CMake version are you using? I'm using 2.8.12 (latest)
-Johan
On 18-11-2013 20:48, Markus Engel wrote:
Actually, I'm not sure why this happens. To me this looks like cmake is behaving differently on linux and on windows/mac. I noticed these missing dependencies in the linking commands, too.
Regards, Markus
-----Ursprüngliche Nachricht----- Von: Johan Engelen [mailto:jbc.engelen@...2592...] Gesendet: Montag, 18. November 2013 20:22 An: Markus Engel Cc: 'inkscape-devel' Betreff: Re: AW: [Inkscape-devel] Trunk r12812 building on Windows for anybody?
On 18-11-2013 20:13, Johan Engelen wrote:
On 16-11-2013 15:54, Markus Engel wrote:
To have the cake and eat it too, we should create shared libraries, not
static libraries. This will run the global init code but also allow us to modularize. However, building shared libraries with Autotools is very annoying. I'd rather we did this after migrating all platforms to CMake / Waf / something other than Autotools which has native support for shared libs.
Hi, I created a new branch at lp:~engelmarkus/inkscape/cmakebuild for this. Currently it should work in Linux. The dom part and all the lib*-folders are compiled into shared objects. I'm just not sure now where they should be installed to. prefix/lib/inkscape probably? I'll try compilation on Windows and Mac OS later this day. The only thing that's missing currently is the cmake installation "code" for these two platforms.
Hi Markus, Open up your branch if you want help!
See the attachment.
The dependency check completes successfully with my patch (previous mail), but linking does not. The commandline for linking does not list any of the dependencies. Output snippet:
FAILED: cmd.exe /c cd . && C:\mingw\bin\c++.exe -shared -o lib/libcola.dll -Wl,--out-implib,lib\libcola.dll.a -Wl,--major-image-version,0,--minor-image-version,0 src/libcola/CMakeFiles/cola.dir/cola.cpp.obj src/libcola/CMakeFiles/cola.dir/conjugate_gradient.cpp.obj src/libcola/CMakeFiles/cola.dir/connected_components.cpp.obj src/libcola/CMakeFiles/cola.dir/gradient_projection.cpp.obj src/libcola/CMakeFiles/cola.dir/shortest_paths.cpp.obj src/libcola/CMakeFiles/cola.dir/straightener.cpp.obj -LD:\inkscape\cmakebuild\inkscape -Lc:\devlibs\lib -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd . Creating library file: lib\libcola.dll.asrc/libcola/CMakeFiles/cola.dir/cola.cpp.obj:cola.cpp:(.tex t+0x1bd): undefined reference to `vpsc::Rectangle::xBorder'
Cheers, Johan
Me, too. Somehow the dependency tracking does not seem to work. Under both Linux and FreeBSD 10 my branch compiles without any changes using cmake. Under Windows and Mac OS cmake seems to forget the dependencies. I don't know why. Maybe it's just some unset variable or so.
Regards, Markus
-----Ursprüngliche Nachricht----- Von: Johan Engelen [mailto:jbc.engelen@...2592...] Gesendet: Montag, 18. November 2013 21:24 An: Markus Engel Cc: 'inkscape-devel' Betreff: Re: AW: AW: [Inkscape-devel] Trunk r12812 building on Windows for anybody?
What CMake version are you using? I'm using 2.8.12 (latest)
-Johan
On 18-11-2013 20:48, Markus Engel wrote:
Actually, I'm not sure why this happens. To me this looks like cmake is behaving differently on linux and on windows/mac. I noticed these missing dependencies in the linking commands, too.
Regards, Markus
-----Ursprüngliche Nachricht----- Von: Johan Engelen [mailto:jbc.engelen@...2592...] Gesendet: Montag, 18. November 2013 20:22 An: Markus Engel Cc: 'inkscape-devel' Betreff: Re: AW: [Inkscape-devel] Trunk r12812 building on Windows for anybody?
On 18-11-2013 20:13, Johan Engelen wrote:
On 16-11-2013 15:54, Markus Engel wrote:
To have the cake and eat it too, we should create shared libraries, not
static libraries. This will run the global init code but also allow us to modularize. However, building shared libraries with Autotools is very annoying. I'd rather we did this after migrating all platforms to CMake / Waf / something other than Autotools which has native support for shared libs.
Hi, I created a new branch at lp:~engelmarkus/inkscape/cmakebuild for this. Currently it should work in Linux. The dom part and all the lib*-folders are compiled into shared objects. I'm just not sure now where they should be installed to. prefix/lib/inkscape probably? I'll try compilation on Windows and Mac OS later this day. The only thing that's missing currently is the cmake installation "code" for these two platforms.
Hi Markus, Open up your branch if you want help!
See the attachment.
The dependency check completes successfully with my patch (previous mail), but linking does not. The commandline for linking does not list any of the dependencies. Output snippet:
FAILED: cmd.exe /c cd . && C:\mingw\bin\c++.exe -shared -o lib/libcola.dll -Wl,--out-implib,lib\libcola.dll.a -Wl,--major-image-version,0,--minor-image-version,0 src/libcola/CMakeFiles/cola.dir/cola.cpp.obj src/libcola/CMakeFiles/cola.dir/conjugate_gradient.cpp.obj src/libcola/CMakeFiles/cola.dir/connected_components.cpp.obj src/libcola/CMakeFiles/cola.dir/gradient_projection.cpp.obj src/libcola/CMakeFiles/cola.dir/shortest_paths.cpp.obj src/libcola/CMakeFiles/cola.dir/straightener.cpp.obj -LD:\inkscape\cmakebuild\inkscape -Lc:\devlibs\lib -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd . Creating library file: lib\libcola.dll.asrc/libcola/CMakeFiles/cola.dir/cola.cpp.obj:cola.cpp :(.tex t+0x1bd): undefined reference to `vpsc::Rectangle::xBorder'
Cheers, Johan
In 2geom, we explicitly add the link dependencies, like:
TARGET_LINK_LIBRARIES(2geom "${LINK_GSL} ${GTK2_LINK_FLAGS}")
Perhaps you have to add that too? (I'm in #inkscape-devel btw)
-Johan
On 18-11-2013 21:27, Markus Engel wrote:
Me, too. Somehow the dependency tracking does not seem to work. Under both Linux and FreeBSD 10 my branch compiles without any changes using cmake. Under Windows and Mac OS cmake seems to forget the dependencies. I don't know why. Maybe it's just some unset variable or so.
Regards, Markus
-----Ursprüngliche Nachricht----- Von: Johan Engelen [mailto:jbc.engelen@...2592...] Gesendet: Montag, 18. November 2013 21:24 An: Markus Engel Cc: 'inkscape-devel' Betreff: Re: AW: AW: [Inkscape-devel] Trunk r12812 building on Windows for anybody?
What CMake version are you using? I'm using 2.8.12 (latest)
-Johan
On 18-11-2013 20:48, Markus Engel wrote:
Actually, I'm not sure why this happens. To me this looks like cmake is behaving differently on linux and on windows/mac. I noticed these missing dependencies in the linking commands, too.
Regards, Markus
-----Ursprüngliche Nachricht----- Von: Johan Engelen [mailto:jbc.engelen@...2592...] Gesendet: Montag, 18. November 2013 20:22 An: Markus Engel Cc: 'inkscape-devel' Betreff: Re: AW: [Inkscape-devel] Trunk r12812 building on Windows for anybody?
On 18-11-2013 20:13, Johan Engelen wrote:
On 16-11-2013 15:54, Markus Engel wrote:
To have the cake and eat it too, we should create shared libraries, not
static libraries. This will run the global init code but also allow us to modularize. However, building shared libraries with Autotools is very annoying. I'd rather we did this after migrating all platforms to CMake / Waf / something other than Autotools which has native support for shared libs.
Hi, I created a new branch at lp:~engelmarkus/inkscape/cmakebuild for this. Currently it should work in Linux. The dom part and all the lib*-folders are compiled into shared objects. I'm just not sure now where they should be installed to. prefix/lib/inkscape probably? I'll try compilation on Windows and Mac OS later this day. The only thing that's missing currently is the cmake installation "code" for these two platforms.
Hi Markus, Open up your branch if you want help!
See the attachment.
The dependency check completes successfully with my patch (previous mail), but linking does not. The commandline for linking does not list any of the dependencies. Output snippet:
FAILED: cmd.exe /c cd . && C:\mingw\bin\c++.exe -shared -o lib/libcola.dll -Wl,--out-implib,lib\libcola.dll.a -Wl,--major-image-version,0,--minor-image-version,0 src/libcola/CMakeFiles/cola.dir/cola.cpp.obj src/libcola/CMakeFiles/cola.dir/conjugate_gradient.cpp.obj src/libcola/CMakeFiles/cola.dir/connected_components.cpp.obj src/libcola/CMakeFiles/cola.dir/gradient_projection.cpp.obj src/libcola/CMakeFiles/cola.dir/shortest_paths.cpp.obj src/libcola/CMakeFiles/cola.dir/straightener.cpp.obj -LD:\inkscape\cmakebuild\inkscape -Lc:\devlibs\lib -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd . Creating library file: lib\libcola.dll.asrc/libcola/CMakeFiles/cola.dir/cola.cpp.obj:cola.cpp :(.tex t+0x1bd): undefined reference to `vpsc::Rectangle::xBorder'
Cheers, Johan
Hi, I added the library dependencies to the CMakeLists in r12821. For me the dlls compile now. Does cmake find "gc/gc.h" or "gc.h" on your system? For me it says not found for both. There must be something wrong with my setup as I can clearly see the file.
Regards, Markus
-----Ursprüngliche Nachricht----- Von: Johan Engelen [mailto:jbc.engelen@...2592...] Gesendet: Montag, 18. November 2013 21:35 An: Markus Engel Cc: 'inkscape-devel' Betreff: Re: AW: AW: AW: [Inkscape-devel] Trunk r12812 building on Windows for anybody?
In 2geom, we explicitly add the link dependencies, like:
TARGET_LINK_LIBRARIES(2geom "${LINK_GSL} ${GTK2_LINK_FLAGS}")
Perhaps you have to add that too? (I'm in #inkscape-devel btw)
-Johan
On 18-11-2013 21:27, Markus Engel wrote:
Me, too. Somehow the dependency tracking does not seem to work. Under both Linux and FreeBSD 10 my branch compiles without any changes using
cmake.
Under Windows and Mac OS cmake seems to forget the dependencies. I don't know why. Maybe it's just some unset variable or so.
Regards, Markus
-----Ursprüngliche Nachricht----- Von: Johan Engelen [mailto:jbc.engelen@...2592...] Gesendet: Montag, 18. November 2013 21:24 An: Markus Engel Cc: 'inkscape-devel' Betreff: Re: AW: AW: [Inkscape-devel] Trunk r12812 building on Windows for anybody?
What CMake version are you using? I'm using 2.8.12 (latest)
-Johan
On 18-11-2013 20:48, Markus Engel wrote:
Actually, I'm not sure why this happens. To me this looks like cmake is behaving differently on linux and on windows/mac. I noticed these missing dependencies in the linking commands, too.
Regards, Markus
-----Ursprüngliche Nachricht----- Von: Johan Engelen [mailto:jbc.engelen@...2592...] Gesendet: Montag, 18. November 2013 20:22 An: Markus Engel Cc: 'inkscape-devel' Betreff: Re: AW: [Inkscape-devel] Trunk r12812 building on Windows for anybody?
On 18-11-2013 20:13, Johan Engelen wrote:
On 16-11-2013 15:54, Markus Engel wrote:
To have the cake and eat it too, we should create shared libraries, not
static libraries. This will run the global init code but also allow us to modularize. However, building shared libraries with Autotools is very annoying. I'd rather we did this after migrating all platforms to CMake / Waf / something other than Autotools which has native support for shared libs.
Hi, I created a new branch at lp:~engelmarkus/inkscape/cmakebuild for this. Currently it should work in Linux. The dom part and all the lib*-folders are compiled into shared objects. I'm just not sure now where they should be installed to. prefix/lib/inkscape probably? I'll try compilation on Windows and Mac OS later this day. The only thing that's missing currently is the cmake installation "code" for these two platforms.
Hi Markus, Open up your branch if you want help!
See the attachment.
The dependency check completes successfully with my patch (previous mail), but linking does not. The commandline for linking does not list any of the dependencies. Output snippet:
FAILED: cmd.exe /c cd . && C:\mingw\bin\c++.exe -shared -o lib/libcola.dll -Wl,--out-implib,lib\libcola.dll.a -Wl,--major-image-version,0,--minor-image-version,0 src/libcola/CMakeFiles/cola.dir/cola.cpp.obj src/libcola/CMakeFiles/cola.dir/conjugate_gradient.cpp.obj src/libcola/CMakeFiles/cola.dir/connected_components.cpp.obj src/libcola/CMakeFiles/cola.dir/gradient_projection.cpp.obj src/libcola/CMakeFiles/cola.dir/shortest_paths.cpp.obj src/libcola/CMakeFiles/cola.dir/straightener.cpp.obj -LD:\inkscape\cmakebuild\inkscape -Lc:\devlibs\lib -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd . Creating library file: lib\libcola.dll.asrc/libcola/CMakeFiles/cola.dir/cola.cpp.obj:cola.cp p :(.tex t+0x1bd): undefined reference to `vpsc::Rectangle::xBorder'
Cheers, Johan
Hi Markus, Great, I'll try when I'm home. CMake finds the garbage collector using pkg-config, and that works fine for me. (check devlibs/lib/pkgconfig/bdw-gc.pc and see if it looks OK)
Cheers, Johan
---- Markus Engel <p637777@...1081...> wrote:
Hi, I added the library dependencies to the CMakeLists in r12821. For me the dlls compile now. Does cmake find "gc/gc.h" or "gc.h" on your system? For me it says not found for both. There must be something wrong with my setup as I can clearly see the file.
Regards, Markus
-----Ursprüngliche Nachricht----- Von: Johan Engelen [mailto:jbc.engelen@...2592...] Gesendet: Montag, 18. November 2013 21:35 An: Markus Engel Cc: 'inkscape-devel' Betreff: Re: AW: AW: AW: [Inkscape-devel] Trunk r12812 building on Windows for anybody?
In 2geom, we explicitly add the link dependencies, like:
TARGET_LINK_LIBRARIES(2geom "${LINK_GSL} ${GTK2_LINK_FLAGS}")
Perhaps you have to add that too? (I'm in #inkscape-devel btw)
-Johan
On 18-11-2013 21:27, Markus Engel wrote:
Me, too. Somehow the dependency tracking does not seem to work. Under both Linux and FreeBSD 10 my branch compiles without any changes using
cmake.
Under Windows and Mac OS cmake seems to forget the dependencies. I don't know why. Maybe it's just some unset variable or so.
Regards, Markus
-----Ursprüngliche Nachricht----- Von: Johan Engelen [mailto:jbc.engelen@...2592...] Gesendet: Montag, 18. November 2013 21:24 An: Markus Engel Cc: 'inkscape-devel' Betreff: Re: AW: AW: [Inkscape-devel] Trunk r12812 building on Windows for anybody?
What CMake version are you using? I'm using 2.8.12 (latest)
-Johan
On 18-11-2013 20:48, Markus Engel wrote:
Actually, I'm not sure why this happens. To me this looks like cmake is behaving differently on linux and on windows/mac. I noticed these missing dependencies in the linking commands, too.
Regards, Markus
-----Ursprüngliche Nachricht----- Von: Johan Engelen [mailto:jbc.engelen@...2592...] Gesendet: Montag, 18. November 2013 20:22 An: Markus Engel Cc: 'inkscape-devel' Betreff: Re: AW: [Inkscape-devel] Trunk r12812 building on Windows for anybody?
On 18-11-2013 20:13, Johan Engelen wrote:
On 16-11-2013 15:54, Markus Engel wrote:
To have the cake and eat it too, we should create shared libraries, not
static libraries. This will run the global init code but also allow us to modularize. However, building shared libraries with Autotools is very annoying. I'd rather we did this after migrating all platforms to CMake / Waf / something other than Autotools which has native support for shared libs.
Hi, I created a new branch at lp:~engelmarkus/inkscape/cmakebuild for this. Currently it should work in Linux. The dom part and all the lib*-folders are compiled into shared objects. I'm just not sure now where they should be installed to. prefix/lib/inkscape probably? I'll try compilation on Windows and Mac OS later this day. The only thing that's missing currently is the cmake installation "code" for these two platforms.
Hi Markus, Open up your branch if you want help!
See the attachment.
The dependency check completes successfully with my patch (previous mail), but linking does not. The commandline for linking does not list any of the dependencies. Output snippet:
FAILED: cmd.exe /c cd . && C:\mingw\bin\c++.exe -shared -o lib/libcola.dll -Wl,--out-implib,lib\libcola.dll.a -Wl,--major-image-version,0,--minor-image-version,0 src/libcola/CMakeFiles/cola.dir/cola.cpp.obj src/libcola/CMakeFiles/cola.dir/conjugate_gradient.cpp.obj src/libcola/CMakeFiles/cola.dir/connected_components.cpp.obj src/libcola/CMakeFiles/cola.dir/gradient_projection.cpp.obj src/libcola/CMakeFiles/cola.dir/shortest_paths.cpp.obj src/libcola/CMakeFiles/cola.dir/straightener.cpp.obj -LD:\inkscape\cmakebuild\inkscape -Lc:\devlibs\lib -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd . Creating library file: lib\libcola.dll.asrc/libcola/CMakeFiles/cola.dir/cola.cpp.obj:cola.cp p :(.tex t+0x1bd): undefined reference to `vpsc::Rectangle::xBorder'
Cheers, Johan
I'm sorry Markus, I now see what you meant. build.xml explicitly adds -I${devlibs}/include/gc, which makes #include <gc.h> work. Because this folder is not added by our CMake script, we instead can set -DHAVE_GC_GC_H. I've modified the CMake script to do this on Windows. Now that part works.
Cheers, Johan
On 19-11-2013 19:02, jbc.engelen@...2592... wrote:
Hi Markus, Great, I'll try when I'm home. CMake finds the garbage collector using pkg-config, and that works fine for me. (check devlibs/lib/pkgconfig/bdw-gc.pc and see if it looks OK)
Cheers, Johan
---- Markus Engel <p637777@...1081...> wrote:
Hi, I added the library dependencies to the CMakeLists in r12821. For me the dlls compile now. Does cmake find "gc/gc.h" or "gc.h" on your system? For me it says not found for both. There must be something wrong with my setup as I can clearly see the file.
Regards, Markus
-----Ursprüngliche Nachricht----- Von: Johan Engelen [mailto:jbc.engelen@...2592...] Gesendet: Montag, 18. November 2013 21:35 An: Markus Engel Cc: 'inkscape-devel' Betreff: Re: AW: AW: AW: [Inkscape-devel] Trunk r12812 building on Windows for anybody?
In 2geom, we explicitly add the link dependencies, like:
TARGET_LINK_LIBRARIES(2geom "${LINK_GSL} ${GTK2_LINK_FLAGS}")
Perhaps you have to add that too? (I'm in #inkscape-devel btw)
-Johan
On 18-11-2013 21:27, Markus Engel wrote:
Me, too. Somehow the dependency tracking does not seem to work. Under both Linux and FreeBSD 10 my branch compiles without any changes using
cmake.
Under Windows and Mac OS cmake seems to forget the dependencies. I don't know why. Maybe it's just some unset variable or so.
Regards, Markus
-----Ursprüngliche Nachricht----- Von: Johan Engelen [mailto:jbc.engelen@...2592...] Gesendet: Montag, 18. November 2013 21:24 An: Markus Engel Cc: 'inkscape-devel' Betreff: Re: AW: AW: [Inkscape-devel] Trunk r12812 building on Windows for anybody?
What CMake version are you using? I'm using 2.8.12 (latest)
-Johan
On 18-11-2013 20:48, Markus Engel wrote:
Actually, I'm not sure why this happens. To me this looks like cmake is behaving differently on linux and on windows/mac. I noticed these missing dependencies in the linking commands, too.
Regards, Markus
-----Ursprüngliche Nachricht----- Von: Johan Engelen [mailto:jbc.engelen@...2592...] Gesendet: Montag, 18. November 2013 20:22 An: Markus Engel Cc: 'inkscape-devel' Betreff: Re: AW: [Inkscape-devel] Trunk r12812 building on Windows for anybody?
On 18-11-2013 20:13, Johan Engelen wrote:
On 16-11-2013 15:54, Markus Engel wrote:
> To have the cake and eat it too, we should create shared > libraries, not static libraries. This will run the global init code but also allow us to modularize. However, building shared libraries with Autotools is very annoying. I'd rather we did this after migrating all platforms to CMake / Waf / something other than Autotools which has native support for shared libs.
Hi, I created a new branch at lp:~engelmarkus/inkscape/cmakebuild for this. Currently it should work in Linux. The dom part and all the lib*-folders are compiled into shared objects. I'm just not sure now where they should be installed to. prefix/lib/inkscape probably? I'll try compilation on Windows and Mac OS later this day. The only thing that's missing currently is the cmake installation "code" for these two platforms.
Hi Markus, Open up your branch if you want help!
See the attachment.
The dependency check completes successfully with my patch (previous mail), but linking does not. The commandline for linking does not list any of the dependencies. Output snippet:
FAILED: cmd.exe /c cd . && C:\mingw\bin\c++.exe -shared -o lib/libcola.dll -Wl,--out-implib,lib\libcola.dll.a -Wl,--major-image-version,0,--minor-image-version,0 src/libcola/CMakeFiles/cola.dir/cola.cpp.obj src/libcola/CMakeFiles/cola.dir/conjugate_gradient.cpp.obj src/libcola/CMakeFiles/cola.dir/connected_components.cpp.obj src/libcola/CMakeFiles/cola.dir/gradient_projection.cpp.obj src/libcola/CMakeFiles/cola.dir/shortest_paths.cpp.obj src/libcola/CMakeFiles/cola.dir/straightener.cpp.obj -LD:\inkscape\cmakebuild\inkscape -Lc:\devlibs\lib -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd . Creating library file: lib\libcola.dll.asrc/libcola/CMakeFiles/cola.dir/cola.cpp.obj:cola.cp p :(.tex t+0x1bd): undefined reference to `vpsc::Rectangle::xBorder'
Cheers, Johan
Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
In "ConfigChecks.cmake" there's already a dynamic check for the location of the gc header that sets the right flag automatically: CHECK_INCLUDE_FILES(gc/gc.h HAVE_GC_GC_H) CHECK_INCLUDE_FILES(gc.h HAVE_GC_H)
This works on Linux, but on Windows it doesn't. And I don't get why.
Regards, Markus
-----Ursprüngliche Nachricht----- Von: Johan Engelen [mailto:jbc.engelen@...2592...] Gesendet: Mittwoch, 20. November 2013 00:34 An: inkscape-devel@lists.sourceforge.net Betreff: Re: [Inkscape-devel] Trunk r12812 building on Windows for anybody?
I'm sorry Markus, I now see what you meant. build.xml explicitly adds -I${devlibs}/include/gc, which makes #include <gc.h> work. Because this folder is not added by our CMake script, we instead can set -DHAVE_GC_GC_H. I've modified the CMake script to do this on Windows. Now that part works.
Cheers, Johan
On 19-11-2013 19:02, jbc.engelen@...2592... wrote:
Hi Markus, Great, I'll try when I'm home. CMake finds the garbage collector using pkg-config, and that works fine for me. (check devlibs/lib/pkgconfig/bdw-gc.pc and see if it looks OK)
Cheers, Johan
---- Markus Engel <p637777@...1081...> wrote:
Hi, I added the library dependencies to the CMakeLists in r12821. For me the dlls compile now. Does cmake find "gc/gc.h" or "gc.h" on your system? For me it says not found for both. There must be something wrong with my setup as I can clearly see the file.
Regards, Markus
-----Ursprüngliche Nachricht----- Von: Johan Engelen [mailto:jbc.engelen@...2592...] Gesendet: Montag, 18. November 2013 21:35 An: Markus Engel Cc: 'inkscape-devel' Betreff: Re: AW: AW: AW: [Inkscape-devel] Trunk r12812 building on Windows for anybody?
In 2geom, we explicitly add the link dependencies, like:
TARGET_LINK_LIBRARIES(2geom "${LINK_GSL} ${GTK2_LINK_FLAGS}")
Perhaps you have to add that too? (I'm in #inkscape-devel btw)
-Johan
On 18-11-2013 21:27, Markus Engel wrote:
Me, too. Somehow the dependency tracking does not seem to work. Under both Linux and FreeBSD 10 my branch compiles without any changes using
cmake.
Under Windows and Mac OS cmake seems to forget the dependencies. I don't know why. Maybe it's just some unset variable or so.
Regards, Markus
-----Ursprüngliche Nachricht----- Von: Johan Engelen [mailto:jbc.engelen@...2592...] Gesendet: Montag, 18. November 2013 21:24 An: Markus Engel Cc: 'inkscape-devel' Betreff: Re: AW: AW: [Inkscape-devel] Trunk r12812 building on Windows for anybody?
What CMake version are you using? I'm using 2.8.12 (latest)
-Johan
On 18-11-2013 20:48, Markus Engel wrote:
Actually, I'm not sure why this happens. To me this looks like cmake is behaving differently on linux and on windows/mac. I noticed these missing dependencies in the linking commands, too.
Regards, Markus
-----Ursprüngliche Nachricht----- Von: Johan Engelen [mailto:jbc.engelen@...2592...] Gesendet: Montag, 18. November 2013 20:22 An: Markus Engel Cc: 'inkscape-devel' Betreff: Re: AW: [Inkscape-devel] Trunk r12812 building on Windows for anybody?
On 18-11-2013 20:13, Johan Engelen wrote:
On 16-11-2013 15:54, Markus Engel wrote:
> To have the cake and eat it too, we should create shared > libraries, not static libraries. This will run the global init code but also allow us to modularize. However, building shared libraries with Autotools is very annoying. I'd rather we did this after migrating all platforms to CMake / Waf / something other than Autotools which has native support for shared libs.
Hi, I created a new branch at lp:~engelmarkus/inkscape/cmakebuild for this. Currently it should work in Linux. The dom part and all the lib*-folders are compiled into shared objects. I'm just not sure now where they should be installed to. prefix/lib/inkscape probably? I'll try compilation on Windows and Mac OS later this day. The only thing that's missing currently is the cmake installation "code" for these two platforms.
Hi Markus, Open up your branch if you want help!
See the attachment.
The dependency check completes successfully with my patch (previous mail), but linking does not. The commandline for linking does not list any of the dependencies. Output snippet:
FAILED: cmd.exe /c cd . && C:\mingw\bin\c++.exe -shared -o lib/libcola.dll -Wl,--out-implib,lib\libcola.dll.a -Wl,--major-image-version,0,--minor-image-version,0 src/libcola/CMakeFiles/cola.dir/cola.cpp.obj src/libcola/CMakeFiles/cola.dir/conjugate_gradient.cpp.obj src/libcola/CMakeFiles/cola.dir/connected_components.cpp.obj src/libcola/CMakeFiles/cola.dir/gradient_projection.cpp.obj src/libcola/CMakeFiles/cola.dir/shortest_paths.cpp.obj src/libcola/CMakeFiles/cola.dir/straightener.cpp.obj -LD:\inkscape\cmakebuild\inkscape -Lc:\devlibs\lib -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd . Creating library file: lib\libcola.dll.asrc/libcola/CMakeFiles/cola.dir/cola.cpp.obj:cola. cp p :(.tex t+0x1bd): undefined reference to `vpsc::Rectangle::xBorder'
Cheers, Johan
-------- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.c lktrk _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
------------------------------------------------------------------------------ Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I made some further changes to the build system. Now Inkscape compiles on Win32, Linux, FreeBsd and Mac OS, as far as I can tell. I rewrote that boehmgc-part. Since we are requiring bdw-gc>=7.0, it is safe to always use "gc/gc.h". The other header is only supplied for backward compatibility. Currently we need a customized FindGTK2 module, but I reported the problem to cmake's bug tracker. This should be fixed soon, I hope. Does Inkscape run for you on Windows now if you copy the generated dlls from lib to bin?
Regards, Markus
-----Ursprüngliche Nachricht----- Von: Johan Engelen [mailto:jbc.engelen@...2592...] Gesendet: Mittwoch, 20. November 2013 00:34 An: inkscape-devel@lists.sourceforge.net Betreff: Re: [Inkscape-devel] Trunk r12812 building on Windows for anybody?
I'm sorry Markus, I now see what you meant. build.xml explicitly adds -I${devlibs}/include/gc, which makes #include <gc.h> work. Because this folder is not added by our CMake script, we instead can set -DHAVE_GC_GC_H. I've modified the CMake script to do this on Windows. Now that part works.
Cheers, Johan
On 19-11-2013 19:02, jbc.engelen@...2592... wrote:
Hi Markus, Great, I'll try when I'm home. CMake finds the garbage collector using pkg-config, and that works fine for me. (check devlibs/lib/pkgconfig/bdw-gc.pc and see if it looks OK)
Cheers, Johan
---- Markus Engel <p637777@...1081...> wrote:
Hi, I added the library dependencies to the CMakeLists in r12821. For me the dlls compile now. Does cmake find "gc/gc.h" or "gc.h" on your system? For me it says not found for both. There must be something wrong with my setup as I can clearly see the file.
Regards, Markus
-----Ursprüngliche Nachricht----- Von: Johan Engelen [mailto:jbc.engelen@...2592...] Gesendet: Montag, 18. November 2013 21:35 An: Markus Engel Cc: 'inkscape-devel' Betreff: Re: AW: AW: AW: [Inkscape-devel] Trunk r12812 building on Windows for anybody?
In 2geom, we explicitly add the link dependencies, like:
TARGET_LINK_LIBRARIES(2geom "${LINK_GSL} ${GTK2_LINK_FLAGS}")
Perhaps you have to add that too? (I'm in #inkscape-devel btw)
-Johan
On 18-11-2013 21:27, Markus Engel wrote:
Me, too. Somehow the dependency tracking does not seem to work. Under both Linux and FreeBSD 10 my branch compiles without any changes using
cmake.
Under Windows and Mac OS cmake seems to forget the dependencies. I don't know why. Maybe it's just some unset variable or so.
Regards, Markus
-----Ursprüngliche Nachricht----- Von: Johan Engelen [mailto:jbc.engelen@...2592...] Gesendet: Montag, 18. November 2013 21:24 An: Markus Engel Cc: 'inkscape-devel' Betreff: Re: AW: AW: [Inkscape-devel] Trunk r12812 building on Windows for anybody?
What CMake version are you using? I'm using 2.8.12 (latest)
-Johan
On 18-11-2013 20:48, Markus Engel wrote:
Actually, I'm not sure why this happens. To me this looks like cmake is behaving differently on linux and on windows/mac. I noticed these missing dependencies in the linking commands, too.
Regards, Markus
-----Ursprüngliche Nachricht----- Von: Johan Engelen [mailto:jbc.engelen@...2592...] Gesendet: Montag, 18. November 2013 20:22 An: Markus Engel Cc: 'inkscape-devel' Betreff: Re: AW: [Inkscape-devel] Trunk r12812 building on Windows for anybody?
On 18-11-2013 20:13, Johan Engelen wrote:
On 16-11-2013 15:54, Markus Engel wrote:
> To have the cake and eat it too, we should create shared > libraries, not static libraries. This will run the global init code but also allow us to modularize. However, building shared libraries with Autotools is very annoying. I'd rather we did this after migrating all platforms to CMake / Waf / something other than Autotools which has native support for shared libs.
Hi, I created a new branch at lp:~engelmarkus/inkscape/cmakebuild for this. Currently it should work in Linux. The dom part and all the lib*-folders are compiled into shared objects. I'm just not sure now where they should be installed to. prefix/lib/inkscape probably? I'll try compilation on Windows and Mac OS later this day. The only thing that's missing currently is the cmake installation "code" for these two platforms.
Hi Markus, Open up your branch if you want help!
See the attachment.
The dependency check completes successfully with my patch (previous mail), but linking does not. The commandline for linking does not list any of the dependencies. Output snippet:
FAILED: cmd.exe /c cd . && C:\mingw\bin\c++.exe -shared -o lib/libcola.dll -Wl,--out-implib,lib\libcola.dll.a -Wl,--major-image-version,0,--minor-image-version,0 src/libcola/CMakeFiles/cola.dir/cola.cpp.obj src/libcola/CMakeFiles/cola.dir/conjugate_gradient.cpp.obj src/libcola/CMakeFiles/cola.dir/connected_components.cpp.obj src/libcola/CMakeFiles/cola.dir/gradient_projection.cpp.obj src/libcola/CMakeFiles/cola.dir/shortest_paths.cpp.obj src/libcola/CMakeFiles/cola.dir/straightener.cpp.obj -LD:\inkscape\cmakebuild\inkscape -Lc:\devlibs\lib -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd . Creating library file: lib\libcola.dll.asrc/libcola/CMakeFiles/cola.dir/cola.cpp.obj:cola. cp p :(.tex t+0x1bd): undefined reference to `vpsc::Rectangle::xBorder'
Cheers, Johan
-------- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.c lktrk _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
------------------------------------------------------------------------------ Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi Markus, Inkscape builds now using CMake and make. If I copy the binaries (/bin and /lib) into a full inkscape "install" folder (using btool), Inkscape quits immediately with errorcode 3.
A separate issue is that CMake + Ninja does not work. This is very unfortunate. btool is *much* faster than CMake+make (in our case), and so it is very important we get Ninja to work. It errors reporting: [1/1] Linking CXX executable bin/inkscape.exe FAILED: cmd.exe /c cd . && C:\mingw\bin\c++.exe -O3 -DNDEBUG @CMakeFiles/inks cape.rsp -o bin/inkscape.exe -Wl,--out-implib,bin\libinkscape.dll.a -Wl,--major -image-version,0,--minor-image-version,0 && cd . c:/mingw/bin/../lib/gcc/mingw32/4.6.1/../../../../mingw32/bin/ld.exe: cannot fin d -lgsl ...
I think there is still something missing in our CMakefile regarding the lib dependencies that Ninja depends on.
regards, Johan
On 24-11-2013 3:30, Markus Engel wrote:
I made some further changes to the build system. Now Inkscape compiles on Win32, Linux, FreeBsd and Mac OS, as far as I can tell. I rewrote that boehmgc-part. Since we are requiring bdw-gc>=7.0, it is safe to always use "gc/gc.h". The other header is only supplied for backward compatibility. Currently we need a customized FindGTK2 module, but I reported the problem to cmake's bug tracker. This should be fixed soon, I hope. Does Inkscape run for you on Windows now if you copy the generated dlls from lib to bin?
Regards, Markus
-----Ursprüngliche Nachricht----- Von: Johan Engelen [mailto:jbc.engelen@...2592...] Gesendet: Mittwoch, 20. November 2013 00:34 An: inkscape-devel@lists.sourceforge.net Betreff: Re: [Inkscape-devel] Trunk r12812 building on Windows for anybody?
I'm sorry Markus, I now see what you meant. build.xml explicitly adds -I${devlibs}/include/gc, which makes #include <gc.h> work. Because this folder is not added by our CMake script, we instead can set -DHAVE_GC_GC_H. I've modified the CMake script to do this on Windows. Now that part works.
Cheers, Johan
On 19-11-2013 19:02, jbc.engelen@...2592... wrote:
Hi Markus, Great, I'll try when I'm home. CMake finds the garbage collector using pkg-config, and that works fine for me. (check devlibs/lib/pkgconfig/bdw-gc.pc and see if it looks OK)
Cheers, Johan
---- Markus Engel <p637777@...1081...> wrote:
Hi, I added the library dependencies to the CMakeLists in r12821. For me the dlls compile now. Does cmake find "gc/gc.h" or "gc.h" on your system? For me it says not found for both. There must be something wrong with my setup as I can clearly see the file.
Regards, Markus
-----Ursprüngliche Nachricht----- Von: Johan Engelen [mailto:jbc.engelen@...2592...] Gesendet: Montag, 18. November 2013 21:35 An: Markus Engel Cc: 'inkscape-devel' Betreff: Re: AW: AW: AW: [Inkscape-devel] Trunk r12812 building on Windows for anybody?
In 2geom, we explicitly add the link dependencies, like:
TARGET_LINK_LIBRARIES(2geom "${LINK_GSL} ${GTK2_LINK_FLAGS}")
Perhaps you have to add that too? (I'm in #inkscape-devel btw)
-Johan
On 18-11-2013 21:27, Markus Engel wrote:
Me, too. Somehow the dependency tracking does not seem to work. Under both Linux and FreeBSD 10 my branch compiles without any changes using
cmake.
Under Windows and Mac OS cmake seems to forget the dependencies. I don't know why. Maybe it's just some unset variable or so.
Regards, Markus
-----Ursprüngliche Nachricht----- Von: Johan Engelen [mailto:jbc.engelen@...2592...] Gesendet: Montag, 18. November 2013 21:24 An: Markus Engel Cc: 'inkscape-devel' Betreff: Re: AW: AW: [Inkscape-devel] Trunk r12812 building on Windows for anybody?
What CMake version are you using? I'm using 2.8.12 (latest)
-Johan
On 18-11-2013 20:48, Markus Engel wrote:
Actually, I'm not sure why this happens. To me this looks like cmake is behaving differently on linux and on windows/mac. I noticed these missing dependencies in the linking commands, too.
Regards, Markus
-----Ursprüngliche Nachricht----- Von: Johan Engelen [mailto:jbc.engelen@...2592...] Gesendet: Montag, 18. November 2013 20:22 An: Markus Engel Cc: 'inkscape-devel' Betreff: Re: AW: [Inkscape-devel] Trunk r12812 building on Windows for anybody?
On 18-11-2013 20:13, Johan Engelen wrote:
On 16-11-2013 15:54, Markus Engel wrote: >> To have the cake and eat it too, we should create shared >> libraries, not > static libraries. This will run the global init code but also > allow us to modularize. However, building shared libraries with > Autotools is very annoying. I'd rather we did this after > migrating all platforms to CMake / Waf / something other than > Autotools which has native support for shared libs. > > Hi, > I created a new branch at lp:~engelmarkus/inkscape/cmakebuild for this. > Currently it should work in Linux. The dom part and all the > lib*-folders are compiled into shared objects. I'm just not sure > now where they should be installed to. prefix/lib/inkscape probably? > I'll try compilation on Windows and Mac OS later this day. The > only thing that's missing currently is the cmake installation > "code" for these two platforms. Hi Markus, Open up your branch if you want help!
See the attachment.
The dependency check completes successfully with my patch (previous mail), but linking does not. The commandline for linking does not list any of the dependencies. Output snippet:
FAILED: cmd.exe /c cd . && C:\mingw\bin\c++.exe -shared -o lib/libcola.dll -Wl,--out-implib,lib\libcola.dll.a -Wl,--major-image-version,0,--minor-image-version,0 src/libcola/CMakeFiles/cola.dir/cola.cpp.obj src/libcola/CMakeFiles/cola.dir/conjugate_gradient.cpp.obj src/libcola/CMakeFiles/cola.dir/connected_components.cpp.obj src/libcola/CMakeFiles/cola.dir/gradient_projection.cpp.obj src/libcola/CMakeFiles/cola.dir/shortest_paths.cpp.obj src/libcola/CMakeFiles/cola.dir/straightener.cpp.obj -LD:\inkscape\cmakebuild\inkscape -Lc:\devlibs\lib -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd . Creating library file: lib\libcola.dll.asrc/libcola/CMakeFiles/cola.dir/cola.cpp.obj:cola. cp p :(.tex t+0x1bd): undefined reference to `vpsc::Rectangle::xBorder'
Cheers, Johan
-------- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.c lktrk _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clk... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi, I changed the owner, this is the new url: lp:~inkscape.dev/inkscape/cmakebuild
Regards, Markus
-----Ursprüngliche Nachricht----- Von: Johan Engelen [mailto:jbc.engelen@...2592...] Gesendet: Montag, 18. November 2013 20:13 An: Markus Engel Cc: 'inkscape-devel' Betreff: Re: AW: [Inkscape-devel] Trunk r12812 building on Windows for anybody?
On 16-11-2013 15:54, Markus Engel wrote:
To have the cake and eat it too, we should create shared libraries, not
static libraries. This will run the global init code but also allow us to modularize. However, building shared libraries with Autotools is very annoying. I'd rather we did this after migrating all platforms to CMake / Waf / something other than Autotools which has native support for shared libs.
Hi, I created a new branch at lp:~engelmarkus/inkscape/cmakebuild for this. Currently it should work in Linux. The dom part and all the lib*-folders are compiled into shared objects. I'm just not sure now where they should be installed to. prefix/lib/inkscape probably? I'll try compilation on Windows and Mac OS later this day. The only thing that's missing currently is the cmake installation "code" for these two platforms.
Hi Markus, Open up your branch if you want help!
See the attachment.
Cheers, Johan
participants (7)
-
unknown＠example.com -
Johan Engelen -
Kris De Gussem -
Krzysztof Kosiński -
LucaDC -
Markus Engel -
mathog