Eduard,

The relocation is not necessary. You can set the environment variables to take care of it. I hit segfault after taking care of the loader.cache file.

In any case, with the new rebuilds you will not have a segfault.

Thanks,
Partha



On Mon, Jan 25, 2016 at 7:48 PM, Eduard Braun <Eduard.Braun2@...173...> wrote:
Turns out I did *not* hit the gdiplus bug you mentioned before.

Instead the error was caused by "gdk-pixbuf" no being able to locate the file "loaders.cache"
The path to this file (by default found in "\lib\gdk-pixbuf-2.0\2.10.0\loaders.cache") is hardcoded in the library and by default an absolute path is used (with your compiled version it would be searched in "Z:/opts/opt64-win32-thread/lib" which obviously does not exist on my system).

The result is that "gdk-pixbuf" is not able to load the loader for XPM. In the following ugly things in the function "sp_load_handles()"  in "select-tool.cpp" are happening:
"gdk_pixbuf_new_from_xpm_data()" fails and returns a null pointer which is fed into "gdk_pixbuf_rotate_simple()" where the segmentation fault happens.

The good news: This can be fixed by setting the "--enable-relocations" flag when configuring "gdk-pixbuff".
Not a nice solution since it needs rebuilding but I wasn't able to find an alternative (except setting the environment variable "GDK_PIXBUF_MODULE_FILE" to point to "loaders.cache", but thats obviously only a workaround).

Regards,
Eduard


Am 25.01.2016 um 15:39 schrieb Partha Bagchi:
Hi Eduard,

It's that gdiplus bug again and I had forgotten about it!! :(

I've re-uploaded the devlibs. You should be OK now. Please check.

I think we should use -std=c++11 which is standard don't you think?

Thanks,
Partha

PS: seems like now I have to use inkscape -g to open the gui. :(




On Sun, Jan 24, 2016 at 9:14 PM, Eduard Braun <Eduard.Braun2@...173...> wrote:
Hi Partha,

thanks for the update! Inkscape compiles (and links!) fine now, also when
using btool.
When using "-std=gnu++0x" it's not even necessary to modify any files (or
might this cause any issues?).

However I'm afraid while compiling works, running does not. Inkscape doesn't
even open before it closes with an internal error...
GDB tells me the error is in gdk_pixbuf_rotate_simple ()
inlibgdk_pixbuf-2.0-0.dll

A quick test shows your "forgotten build" might have the same issue? Running
inkscape -g fails with (inkscape.exe:7532): GdkPixbuf-CRITICAL **:
gdk_pixbuf_read_pixels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed for me.
Did it work for work for you?

Good night,
Eduard


Am 24.01.2016 um 23:07 schrieb Partha Bagchi:
Eduard,

I have updated the devlibs with the missing libraries. it now includes
the Readme.txt in the base folder. Please download from the same
place.

I didn't have issues with building inkscape-r14615. My command line was:
   ./configure --prefix=/opt/inkscape --build=x86_64-w64-mingw32
LIBS="-L/opt/lib -L/usr/python/Lib" CPPFLAGS="-I/opt/include
-I/usr/python/include" CFLAGS="-w -O3 -ffast-math -ftree-vectorize"
CXXFLAGS="-w -std=c++11 -O3 -ffast-math -ftree-vectorize"

The boost notes and warnings are annoying and so I suppressed them. :)

Since a whole bunch M_PI, M_PI_2, etc are undefined due to using
-std=c++11, I modified the source by hand to fix those. Also, couple
of files have WIN32 defined as opposed to _WIN32.

Please let me know if you have any questions.

Thanks,
Partha



On Sun, Jan 24, 2016 at 10:18 AM, Eduard Braun <Eduard.Braun2@...173...>
wrote:
Seems my last mail didn't get through (probably because of pasted text),
so
here we go again...

I can't seem to get the win64 build working. Inkscape is compiling fine
but
I'm always getting linker errors:

      https://inkscape.org/de/gallery/item/7421/

Here's the command used by btool:

      https://inkscape.org/de/gallery/item/7426/


Any idea what's going wrong (and how to fix it)?

Regards,
Eduard

Am 23.01.2016 um 21:22 schrieb Eduard Braun:
Am 23.01.2016 um 20:28 schrieb Partha Bagchi:
On Sat, Jan 23, 2016 at 1:06 PM, Eduard Braun <Eduard.Braun2@...173...>
wrote:
I finally got around to have a look at the 64-bit devlibs Partha
provided.
I'm afraid however that I didn't succeed to build Inkscape with them
yet
(this is really not my area of expertise so any help is *very*
welcome!).

I'll take a look into building it for you if that helps?
Obviously you have more experience, so I guess you'd be able to figure
out what is going wrong. Probably it's just some stupid error of mine
which would be trivial to fix ;-). I don't want you to feel obliged,
though, especially with respect to my next comment...
What I noticed so far:
The new devlibs are based on a MinGW build with win32 threads and SEH
exception handling (possibly
x86_64-5.3.0-release-win32-seh-rt_v4-rev0.7z,
see [1]) whereas the old devlibs are based on MinGW with posix threads
and
SJLJ exception handling
(x86_64-4.9.0-release-posix-sjlj-rt_v3-rev1.7z,
see
[2]).

I think the previous 64-bit devlibs were also built with SEH and using
4.9.2. See this thread:
http://sourceforge.net/p/inkscape/mailman/message/34099214/
Oh, wow, I didn't know about these... I based my work on the latest
64-bit devlibs available on launchpad
(https://code.launchpad.net/~inkscape.dev/inkscape-devlibs64/trunk) and
those date back to 2014 (with the readme stating posix/sjlj was in use,
no idea if that's correct). I assume your updated builds never made it
into the public repository.
So my first question is if this would work with Inkscape in principle?
Not
that I (or anybody else) try to make something work that can not work
to
start with...

In case win32 threads and SEH exception handling are OK for Inkscape I
suppose we'd also need to rebuild all other dependencies with the new
compiler? (Again, I have no clue about these things, but from what I
got
from a quick Internet search the old and new binaries are not
compatible?)

Which other dependencies need to be built?
Only those I listed... some of these are in your package from
2015-05-10, though, so a new built might not be necessary.
Libraries that I spotted which are currently not included in the new
devlibs-package:

gtkmm/gdkmm 2.4 (the package includes only 3.0)
gtkmm 2.4 series is out dated. Do we still use it? With the move to
GTK3, this should not be needed?
As far as I know GTK3 is still experimental, normal builds still use
GTK2.
aspell
aspell is optional.
Yes, sorry for not being more specific.
We have it i current builds but I assume it's not mandatory.
ImageMagick
Oops, my bad. I'll update the libs.
Thanks, no problem!
poppler-data (for eastern-character support)
ditto.
librevenge (optional if we want to include newer versions of the
various
import libraries [3])

OK, I'll build this too.
Regards,
Eduard

[1] http://www.partha.com/temp/Readme.txt
[2]


http://bazaar.launchpad.net/~inkscape.dev/inkscape-devlibs64/trunk/view/head:/readme.txt
[3] http://www.documentliberation.org/projects/


Am 17.01.2016 um 20:34 schrieb Partha Bagchi:

Hi Eduard,

I have uploaded the Windows 64bit devlibs here:
http://www.partha.com/temp/inkscape-devlibs.7z

Can you (or someone) upload it to its final destination? The devlibs
include potrace 1.13.

Please let me know if you have any questions.

Thanks,
Partha


On Fri, Jan 15, 2016 at 9:07 PM, Eduard Braun <Eduard.Braun2@...173...>
wrote:

If you have some time this weekend, then adding potrace to the 64bit
devlibs
should probably be a high priority.
Right now it breaks 64bit builds since it seems the logic for
excluding
code
depending on potrace if it's not available does not work for
btool-based
builds (at least I was not able to make it work)

Regards,
Eduard


Am 11.01.2016 um 11:42 schrieb Partha Bagchi:

On Mon, Jan 11, 2016 at 5:15 AM, Nicolas Dufour <nicoduf@...48...>
wrote:
...

To be honest, I'm a bit lost and can't find the best solution for us.
Could anyone (Partha, Johan, Krzysztof, or someone else) give an
advice?
Partha, how do you build the 64bit devlibs?

There are some points we need to take into consideration (I probably
forgot some):
* The new devlibs must be easier to maintain compared to the current
ones.
* It should be possible to use the same steps to update win32 and
win64
devlibs.
* If both devlibs could provide exactly the same packages versions, it
would greatly help bug tracking (and fixing)...
* Do we still need to link libstdc++ statically? (Opensuse
cross-compiled
packages need a shared library.)

Regards,
--
Nicolas

Nicolas,

I build my 64bit libs from scratch. I use MSYS as my shell if you will
and gcc 5.1.0 as my compiler.

No, I don't think you have to statically link libstdc++.

I'll try to provide a 64bit devlibs build this weekend if that's not
too
late.

Thanks,
Partha




------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel



------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel