On 28/04/15 12:22, Emil Velikov wrote:
On 28 April 2015 at 11:16, Jose Fonseca wrote:
Hi,
I don't know if in the end of this thread there was an agreement that Valve
should only use bundled libstdc++ if it's newer than the system's libstdc++,
or just no agreement at all.
It seems to me tha
On 28 April 2015 at 11:16, Jose Fonseca wrote:
> Hi,
>
>
> I don't know if in the end of this thread there was an agreement that Valve
> should only use bundled libstdc++ if it's newer than the system's libstdc++,
> or just no agreement at all.
>
>
It seems to me that there is no agreement atm :-(
Hi,
I don't know if in the end of this thread there was an agreement that
Valve should only use bundled libstdc++ if it's newer than the system's
libstdc++, or just no agreement at all.
But just for future reference (or in case any distro decides to apply
the patches themselves), I'd like
On Thu, Mar 12, 2015 at 16:15:56 +0900, Michel Dänzer wrote:
> On 11.03.2015 05:07, Vivek Dasmohapatra wrote:
> > Hi - As you probably already know, there can only be one version of
> > libstdc++.so in your runtime link chain - This is usually not a problem,
> > but when things are linked against
On 16/03/15 23:44, Ian Romanick wrote:
> On 03/13/2015 02:32 PM, Emil Velikov wrote:
>> * Allow people to static link against libgcc/libstdc++.
>>
>> Imho this should be option, disabled by default provided at configure
>> time. This way builders/distributions can op-in if they choose to do so.
>
On 03/13/2015 02:32 PM, Emil Velikov wrote:
> * Allow people to static link against libgcc/libstdc++.
>
> Imho this should be option, disabled by default provided at configure
> time. This way builders/distributions can op-in if they choose to do so.
I'm very strongly opposed to this.
We alread
Emil Velikov writes:
> On 14 March 2015 at 13:04, Emil Velikov wrote:
>> On 13/03/15 22:10, Francisco Jerez wrote:
>>> Emil Velikov writes:
> ...
* Use bundled library if newer (check the SONAME).
For libgcc_s at least, the library does not seems to be forward compatible.
>
On 14 March 2015 at 13:04, Emil Velikov wrote:
> On 13/03/15 22:10, Francisco Jerez wrote:
>> Emil Velikov writes:
...
>>>
>>> * Use bundled library if newer (check the SONAME).
>>>
>>> For libgcc_s at least, the library does not seems to be forward compatible.
>>>
>>
>> That belongs to your lis
On 13/03/15 22:10, Francisco Jerez wrote:
> Emil Velikov writes:
>
>> Hi all,
>>
>> Allow me to sum all that is said here, plus elaborate on some of the
>> myths and alternative solutions proposed.
>>
>> Considering that this is a never ending and somewhat emotional topic, I
>> would kindly ask p
Emil Velikov writes:
> Hi all,
>
> Allow me to sum all that is said here, plus elaborate on some of the
> myths and alternative solutions proposed.
>
> Considering that this is a never ending and somewhat emotional topic, I
> would kindly ask people to read this while in their happy place.
>
>
>
Hi all,
Allow me to sum all that is said here, plus elaborate on some of the
myths and alternative solutions proposed.
Considering that this is a never ending and somewhat emotional topic, I
would kindly ask people to read this while in their happy place.
Myths
-
* "The LLVM-enabled varia
On 13.03.2015 03:07, Pierre-Loup A. Griffais wrote:
> On 03/11/2015 09:40 AM, Ian Romanick wrote:
>> On 03/11/2015 09:31 AM, Tobias Klausmann wrote:
>>> The problem in not forcing this to link statically is, that if a
>>> distribution decides to not use this static option, the problem persists
>>>
On 03/11/2015 09:40 AM, Ian Romanick wrote:
On 03/11/2015 09:31 AM, Tobias Klausmann wrote:
The problem in not forcing this to link statically is, that if a
distribution decides to not use this static option, the problem persists
on that distribution. On top every lib pulled in by steam from the
Michel Dänzer wrote on 12.03.2015 08:15:
> On 11.03.2015 05:07, Vivek Dasmohapatra wrote:
>> Hi - As you probably already know, there can only be one version of
>> libstdc++.so in your runtime link chain - This is usually not a problem,
>> but when things are linked against the Steam runtime (for e
Ian Romanick writes:
> On 03/11/2015 09:31 AM, Tobias Klausmann wrote:
>> The problem in not forcing this to link statically is, that if a
>> distribution decides to not use this static option, the problem persists
>> on that distribution. On top every lib pulled in by steam from the
>> system wo
On Wed, Mar 11, 2015 at 12:40 PM, Ian Romanick wrote:
> On 03/11/2015 09:31 AM, Tobias Klausmann wrote:
>> The problem in not forcing this to link statically is, that if a
>> distribution decides to not use this static option, the problem persists
>> on that distribution. On top every lib pulled i
On 11/03/15 16:01, Francisco Jerez wrote:
Vivek Dasmohapatra writes:
Hi -
Hi,
As you probably already know, there can only be one version of
libstdc++.so in your runtime link chain
That's a common misconception, in principle several versions of
libstdc++.so with different DT_SONAME (i.e.
Hi - As you probably already know, there can only be one version of
libstdc++.so in your runtime link chain - This is usually not a problem,
but when things are linked against the Steam runtime (for example), they
can end up with two - one from the steam runtime, and one pulled in via
the mesa dri
Vivek Dasmohapatra writes:
> Hi -
Hi,
> As you probably already know, there can only be one version of
> libstdc++.so in your runtime link chain
That's a common misconception, in principle several versions of
libstdc++.so with different DT_SONAME (i.e. with mutually incompatible
ABIs) can be l
On 11.03.2015 05:07, Vivek Dasmohapatra wrote:
> Hi - As you probably already know, there can only be one version of
> libstdc++.so in your runtime link chain - This is usually not a problem,
> but when things are linked against the Steam runtime (for example), they
> can end up with two - one from
Here's a version of the mesa build patches rolled into one patch,
and driven by a configure argument --enable-static-libstdc++
which defaults to being off.From 2e967e89fefc2a107c29c6581c9885475a7b7a84 Mon Sep 17 00:00:00 2001
From: vivek
Date: Thu, 12 Mar 2015 01:30:19 +
Subject: [PATCH 1/2]
On 03/11/2015 09:32 AM, Jose Fonseca wrote:
> I can almost bet that NVIDIA uses C++ somewhere, but no dependencies on
> libstdc++. Not sure if they chose to statically link libstdc++ to
> support multiple distros, or to avoid issues like applications shipping
> their own libstdc++...
My recollect
On 03/11/2015 09:31 AM, Tobias Klausmann wrote:
> The problem in not forcing this to link statically is, that if a
> distribution decides to not use this static option, the problem persists
> on that distribution. On top every lib pulled in by steam from the
> system would need to be link staticall
On 11.03.2015 17:01, Francisco Jerez wrote:
Vivek Dasmohapatra writes:
Hi -
Hi,
As you probably already know, there can only be one version of
libstdc++.so in your runtime link chain
That's a common misconception, in principle several versions of
libstdc++.so with different DT_SONAME (i.
24 matches
Mail list logo
