corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <>
Subject Re: libxml2 and iconv question, do we really need iconv ?
Date Mon, 23 Mar 2015 14:53:26 GMT
On 23 March 2015 at 15:31, Peter Kelly <> wrote:

> Also I just realised that SDL2, SDL2_image, and even zlib are in 3rd
> party. This brings the total size of our source tree to 165 mb. Before that
> it was 41 Mb. Could we *please* not have these in there?
> Dennis raised the point previously about it being a bad idea to provide
> our own binary distributions of these libraries - a point I disagreed with
> (I think it is useful to do so, for convenience purposes). But I definitely
> think the sources to other projects do not belong in our own repository.
> The issues of size (medium) and responsibility for updating after security
> vulnerabilities are found in these (major) are the main reasons for my
> objection, but another minor one is that these are not Apache licensed.

As I just wrote in another mail, we need nearly all of them to be able to
do the 64bit for windows.

A lot of projects do like I just did, and often for the same purpose to be
able to compile the library so it fits the need of the project.

The only alternative I can see, is that I compile them and make them
available as zip files, that reduces the size of everybody else repo, but
we still have update problems etc. Looking at the revision history of these
libraries, they do not exactly have many updates.

Can anyone suggest another alternative:
I need 32bit and 64bit libs (prefer no-shared, because shared is gives dll
conflicts when testing).

We need both a release version and a debug version (to avoid linker

We also need a way to avoid dependency on iconv.

jan i.

> —
> Dr Peter M. Kelly
> PGP key: <>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
> > On 23 Mar 2015, at 9:04 pm, Peter Kelly <> wrote:
> >
> > (apologies if this is duplicated; I sent from the wrong address before)
> >
> > I have about 70% of an XML parser done that I haven’t gotten around to
> finishing yet. Once that’s completed, we don’t need libxml. I can’t
> remember if we need iconv; it’s used for character set conversions but
> DocFormats is UTF-8 native (as is libxml), and support for UTF-16 would not
> be hard (if it’s even needed).
> >
> > I would strongly argue against keeping sources of libraries in our
> repositories except in the case where we have made changes to those
> libraries. If we do that we have to include all of SDL_image and thus all
> of SDL, and that leads to quite a big repository. The same goes for libz
> etc. Most projects have lots and lots of dependencies and are handled just
> fine by standard package dependency systems e.g. apt-get.
> >
> > Furthermore, we want to use the system libxml where available, both to
> take advantage of shared libraries (libxml only needs to exist in memory
> once, the OS maps it into the address space of each process that uses it),
> and for security updates (system libxml updated due to vulnerability,
> programs using DocFormats are still vulnerable until we go and update our
> own version).
> >
> > —
> > Dr Peter M. Kelly
> >
> >
> > PGP key: <
> > (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
> >
> >> On 23 Mar 2015, at 3:29 pm, jan i <> wrote:
> >>
> >> Hi.
> >>
> >> I am nearly finished with the x64 port for windows, I have compiled all
> >> libraries we need.
> >>
> >> I wanted to see if we could keep the library sources in our Repo, and
> >> integrate them in our build
> >> system, as it would simplify things. Since I am biased I asked on
> >> general@i.a.o to get the opinion
> >> of outside Mentors. I got a few responses (strangely enough all in
> >> private), and it turns out many projects do as I suggest.
> >>
> >> However one of the others mentors found a license problem with iconv.
> We do
> >> not use iconv, but by default libxml2 does. I can configure libxml2 not
> to
> >> include iconv, but I wanted to ask in here, if we need the
> functionality ?
> >>
> >> If not my plan has changed a bit, and I will include the sources in
> >> platform, make a single commit with each original source, noting the URL
> >> and version in the commit text (and add it to LICENSE). Then I will add
> my
> >> changes, which will be solely CMAKE files NO source changes.
> >>
> >> Having the source in our build system, will also allow us to decide how
> to
> >> handle other platforms.
> >>
> >> Rgds
> >> jan I.
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message