Port request: librsvg (for windows).

[Lord-Kamina]

Please add a librsvg port; it's a relatively low-level library to render svg files with cairo, it's pretty widely used in GNOME, among other things. In recent versions they've begun migrating the code to rust, but perhaps you could port version 2.40.20, which was the last before they began doing this.

https://download.gnome.org/sources/librsvg/2.40/

Currently, 2.40 releases can be built with MXE on Linux and Mac, and also with MSYS2. I wanted to give it a go myself but honestly converting stuff from autotools seems a bit daunting.

[Kwizatz]

I just uploaded a PR for libcroco at #6467 libcroco is the only librsvg dependency missing from vcpkg.

I have a port for librsvg ready as well, but since it depends on libcroco to build, I'll upload it after this one is merged.

[Lord-Kamina]

Awesome! really hoping it gets merged!

[Kwizatz]

libcroco merged, I have a librsvg building and installing on msvc, but there's some issues on Linux which will prevent it from merging. In short, Linux gdk-pixbuf is broken on master.

The long story is that gdk-pixbuf uses glib, which uses gettext, which uses empty package (it basically doesn't fail the build but does not install anything either), so later, when gdk-pixbuf looks for libintl, it fails.

I tried fixing gettext but that ended up with libiconv presenting the same issue and then pthreads, which doesn't even have a general source package distribution.

So that's where I'm at, perhaps it would be a good idea to file a bug for gdk-pixbuf broken on Linux, but who knows how long it may take for it to get fixed.

I'll try again without setting VCPKG_ROOT, maybe it just needs to find the system libraries.

[Kwizatz]

Update: gdk-pixbuf is definitely broken on Linux.

[NNemec]

@Kwizatz - does the port include the gdk-pixbuf loader? I have a project fully compiling and running on MSVC. The biggest issue right now is that gdk-pixbuf cannot load the SVG icons. My understanding is that this loader module from librsvg is the piece that is missing.

Where can I find that librsvg port of yours?

[Kwizatz]

@NNemec - I think it does, I have made changes to libiconv, gettext, glib, gdk-pixbuf and I got all dependencies building on Linux, however, librsvg (On Linux) itself needs some work before I upload the fix and the new port.

I'll try to publish something later today, but in the meantime, it's all local to my pc.

[NNemec]

Excellent! If it takes longer, I'd be happy to try out whatever preliminary version you have.

[Kwizatz]

PR #6625 is up with necessary changes on dependencies to build librsvg on Linux.
With these changes the librsvg port gets build on both MSVC and Linux.

I checked and currently my port does not build the pixbuf loader, I'll be adding it soon and I'll post a gist or similar if it takes too long for #6625 to merge.

[Kwizatz]

So, I created PR #6663 which has a better chance of merging than #6625.

@NNemec I have added the dll part of the loader as part of the build for the librsvg port, however, that's as far as I can go, as I have no idea on how it works or how it interfaces with gdk-pixbuf. I'll leave that up to you once the port is up. I have the librsvg port ready, just need #6663 to merge to put that one up as well.

[NNemec]

Sounds good! I'll have some spare time to invest on upcoming Mon&Tue, so if you could just push the changes to a temporary branch on github (no PR needed) I'd be happy to try them out and see whether I get the gdk-pixbuf loader module working.

[Kwizatz]

You can access the port at:

https://github.com/Kwizatz/vcpkg/tree/librsvg-port

These are the relevant files if you just want to manually copy them over to your setup:

https://github.com/Kwizatz/vcpkg/tree/librsvg-port/ports/librsvg

It should work as is on Windows+MSVC, but if it does not, cherry pick #6663

[NNemec]

I managed to build librsvg on that branch. One necessary correction: CMakeLists.txt:101:

• unofficial::libcroco::croco-0.6

• unofficial::libcroco::libcroco
  (I guess that -0.6 was based on some preliminary version of your libcroco port...)
  Now I'll look into using the gdk-pixbuf module.

[Kwizatz]

Yes, #6663 changes libcroco library name to croco-6 to be more consistent with what you get on Linux and MSYS2, right now while the MSVC version seems fine, on linux the archive file name is liblibcroco.a, which is not only redundant, but also not what you expect the library to be named on gcc based systems.

[NNemec]

Making progress on loading pixbufloader-svg, but it is tough going...

So far, I managed to manually install the various .dlls and create the necessary loaders.cache so that gdk-pixbuf attempts to load the .dll - at that point, the loading fails due to naming conflict:

A debug build of rsvg-2.40 appears to depend on cairo.dll, but the debug version of that file is actually called cairod.dll (which is also used by my application)

Furthermore, I noticed that none of rsvg-2.40.dll nor pixbufloader-svg.dll or croco-0.6.dll have their .pdb installed. Not a blocker for me, but should probably be fixed nonetheless.

With these findings, I will put the project on ice for the next 10 days while I enjoy my vacation...

[Kwizatz]

Installing the pdb files shouldn't be hard, just add the file to the install commands at the end of the respective portfiles/CMakeLists.

the cairo dependency may have to be more with the cairo port than librsvg, the "unofficial" config files may not be properly adding the debug versions to the internal library targets.

I'll look it up, but not sure how soon.

[Kwizatz]

I've fixed the pdb files issue on the librsvg-port branch, not sure why the debug version is linking against the release cairo lib though. The port uses the unofficial::cairo target which should already be set up to link to the correct version, but I may have missed something.

[Kwizatz]

@NNemec Upon checking the imports for the debug versions of both the library and the loader they are linking against the correct debug versions. Note however that the names for the debug versions also have the "d" suffix (rsvg-2.40d.dll, pixbufloader-svgd.dll) so I am guessing that you were using pixbufloader-svg.dll for your tests and that's why you're getting the error. If the loader MUST be used without the "d" suffix I can make the change, but first try renaming and copying over the debug dll to match the requirements of your setup.

[NNemec]

@Kwizatz Indeed - pure stupidity on my side. In all the manual copying around I had ultimately actually copied the release versions of these libraries. Sorry about wasting your time.

However: What is see now in Dependency Walker is that rsvg-2.40d.dll depends on croco-0.6.dll, even though the debug version is called croco-0.6d.dll:

I don't have the time right now to dig deeper to verify this, though...

[Kwizatz]

@NNemec I am seeing that as well. I think you can rename the debug dll without issues since only librsvg should be linking against it. I'll find out what the issue is there.

Update: it seems like I am missing the file unofficial-libcroco-targets-debug.cmake and unofficial-librsvg-targets-debug.cmake from the installation. I have a suspicion that clearing the debug folders is what is the problem here. if that's the issue I'll be updating the PR and the branch with the fix soon.

[Kwizatz]

@NNemec I've fixed both the PR and the branch, now anything linking against the debug version of either librsvg or libcroco should link to the proper file.

[Kwizatz]

The Linux fix PR has merged, I'll submit the librsvg port now.

[Kwizatz]

Port has merged, you can close this issue.

[NancyLi1013]

@Lord-Kamina, thanks for posting this request. @Kwizatz, thanks for your PR.

[proTerm]

You should reopen this issue. The static build is not completed yet.

[Febbe]

There is also a pkg-config (.pc) file missing