On Tue, Jan 30, 2018 at 4:47 PM, Tom Kacvinsky wrote:
> I am guessing your hesitance is more based on the principle of the
> matter, not the additional work it would take (since I am going to do it).
>
You are right. I also hated the frontend of the symbol versions which
requires GCC assembler t
Well, that is inspirational enough - let's be the first to do historical
versioning instead of slapping a single
version on each symbol with each iteration of the API.
I mean, I am willing to do the work, so I am guessing your hesitance is
more based on the principle of the
matter, not the additio
On Tue, Jan 30, 2018 at 3:30 PM, Behdad Esfahbod
wrote:
> I want to hear from downstreams that want to add symbol-versioning to
> FreeType first, why do they need to.
>
I need some inspiration, some good examples to follow. Besides glibc, so
far I've only seen silly wrappers that slap a single v
I want to hear from downstreams that want to add symbol-versioning to
FreeType first, why do they need to.
On Tue, Jan 30, 2018 at 12:22 PM, Tom Kacvinsky wrote:
> You raise a fair point. The point I was trying to make, and perhaps I
> didn't make it clear enough
> what I was after, is this: su
You raise a fair point. The point I was trying to make, and perhaps I
didn't make it clear enough
what I was after, is this: suppose some downstream maintainer decides to
add symbol versions.
Wouldn't it be nice if we already had that so there is no mess between how
one Linux distribution
does it
I know what symbol versioning is used for (I was also package maintainer at
Red Hat for four years). But don't see how it applies to FreeType.
FreeType never changes ABI in backward-incompatible way. Its build system
is already adhoc enough. I don't want to see more complexity added
unnecessarily.
> Despite all of the talk about whether symbol versioning is useful
> (and this is not meant to be snarky), keep in mind the major
> commercial Linux distributions use symbol versioning, as well as the
> free Linux distributions.
No doubt that it is useful. However, we lack experience, and there
> I'm new to open source , and would like to contribute as much as
> possible. I found your organization quite interesting and will be
> glad to work with you on any task you care to assign me.
You are too early. On Feb. 12th Google will announce the
participating organizations.
Regardless of
Hi
I'm new to open source , and would like to contribute as much as possible.
I found your organization quite interesting and will be glad to work with
you on any task you care to assign me.Please guide me in any way possible.
Thanking You
Mratyunjay Soni
_
On 01/30/18 05:33 AM, Tom Kacvinsky wrote:
> Well, if Solaris for x86_64 is freely available and uses symbol versioning
> exactly the same way
> Solaris for SPARC does, I can got hat route.
You can download free versions for development purposes, just not production,
and you won't get patches for
Well, if Solaris for x86_64 is freely available and uses symbol versioning
exactly the same way
Solaris for SPARC does, I can got hat route. What I was after is I might
be able to get access
to SPARC bare metal hardware with Solaris 8, 9 or 10.
On Tue, Jan 30, 2018 at 7:48 AM, Vincent Torri
wrot
On Tue, Jan 30, 2018 at 1:45 PM, Tom Kacvinsky wrote:
> Hi all,
>
> I'll see what I can do. To be honest, the only platforms that really
> support this
> are Linux and Solaris. I definitely have access to Linux machines, but not
> a
> Solaris machine. I might be able to get access to the latter
Hi all,
I'll see what I can do. To be honest, the only platforms that really
support this
are Linux and Solaris. I definitely have access to Linux machines, but not
a
Solaris machine. I might be able to get access to the latter.
Despite all of the talk about whether symbol versioning is useful
13 matches
Mail list logo
