Lisandro Damián Nicanor Pérez Meyer writes:
> Sometimes we may expect FTBFSs due to changes in other archs toolchains not
> catched by the local arch, like missing symbols. This is when this may come
> handy:
> override_dh_makeshlibs:
> dh_makeshlibs -- -c0
> If in your local arch you
On Sáb 28 Ene 2012 02:28:25 Russ Allbery escribió:
[snip]
> 2. Build and upload this version of the package. Now wait for all the
>buildds to fail (because they will, on probably nearly every other
>architecture than your local one).
Sometimes we may expect FTBFSs due to changes in other
Chow Loong Jin writes:
> On 29/01/2012 08:19, Russ Allbery wrote:
>> Oh, hey, indeed. Right, I didn't realize the implication of what you
>> were saying.
>> So... what if dpkg-gensymbols implicitly marked all weak symbols as
>> optional and didn't care if they disappeared? Would that make sens
On 29/01/2012 08:19, Russ Allbery wrote:
> Chow Loong Jin writes:
>
>> $ nm -CD libfoo.so | awk '$2 == "W" {print;}'
>
>> I mentioned that the inlined symbols are all weak symbols. If the
>> library you're maintaining doesn't do use __attribute__((weak)), then
>> all the weak symbols present sh
Chow Loong Jin writes:
> $ nm -CD libfoo.so | awk '$2 == "W" {print;}'
> I mentioned that the inlined symbols are all weak symbols. If the
> library you're maintaining doesn't do use __attribute__((weak)), then
> all the weak symbols present should be inlined and optional.
Oh, hey, indeed. Ri
On 29/01/2012 07:48, Russ Allbery wrote:
> Chow Loong Jin writes:
>> On 29/01/2012 07:18, Russ Allbery wrote:
>
>>> What I'm seeing (I think; I'm not positive) is that an inline function
>>> (generally inlined because it's defined inside the class definition,
>>> not due to explicit keywords) app
Chow Loong Jin writes:
> On 29/01/2012 07:18, Russ Allbery wrote:
>> What I'm seeing (I think; I'm not positive) is that an inline function
>> (generally inlined because it's defined inside the class definition,
>> not due to explicit keywords) appears and disappears from the export
>> list of th
On 29/01/2012 07:18, Russ Allbery wrote:
> Chow Loong Jin writes:
>> On 29/01/2012 06:20, Russ Allbery wrote:
>
>>> Right, I think Qt is quite possibly the best maintained C++ library of
>>> significant size out there. I'm not saying that the benefit isn't
>>> worth it for fairly well-maintained
Chow Loong Jin writes:
> On 29/01/2012 06:20, Russ Allbery wrote:
>> Right, I think Qt is quite possibly the best maintained C++ library of
>> significant size out there. I'm not saying that the benefit isn't
>> worth it for fairly well-maintained libraries, *particularly* if they
>> do symbol e
On 29/01/2012 06:20, Russ Allbery wrote:
> Sune Vuorela writes:
>> On 2012-01-28, Russ Allbery wrote:
>
>>> 5. It's still not clear that the benefit is worth the amount of effort,
>>>since I expect most C++ libraries to require frequent SONAME changes
>>>anyway, which means that the long
Steve McIntyre writes:
> Russ Allbery wrote:
>> And indeed, this process has already broken. Take a look at:
>>
>> https://buildd.debian.org/status/logs.php?pkg=opensaml2&arch=ia64&ver=2.4.3-3
> To be honest, for me this thread is just confirming my
> prejudice^Wjudgement that C++ is just a bad
Sune Vuorela writes:
> On 2012-01-28, Russ Allbery wrote:
>> 5. It's still not clear that the benefit is worth the amount of effort,
>>since I expect most C++ libraries to require frequent SONAME changes
>>anyway, which means that the long-term binary compatibility angle of
> Qt has kep
On 2012-01-28, Russ Allbery wrote:
> 5. It's still not clear that the benefit is worth the amount of effort,
>since I expect most C++ libraries to require frequent SONAME changes
>anyway, which means that the long-term binary compatibility angle of
Qt has kept binary compatibility since 4
Russ Allbery wrote:
>Russ Allbery writes:
>
>And indeed, this process has already broken. Take a look at:
>
>https://buildd.debian.org/status/logs.php?pkg=opensaml2&arch=ia64&ver=2.4.3-3
To be honest, for me this thread is just confirming my
prejudice^Wjudgement that C++ is just a bad choice of
Russ Allbery writes:
> However, it does have some problems, some obvious, and some more subtle.
> Here's a list of the issues that I see:
> 1. It feels like this symbols file is still likely to be fragile. While
>pkg-kde-tools detects a *lot* of template instances and marks them
>option
Okay, I've spent parts of another couple of days working on this using the
pkg-kde-tools infrastructure, and I think I can draw some more
conclusions.
First of all, for those who haven't explored the pkg-kde-tools
infrastructure for this, it looks like the effective process goes
something like thi
16 matches
Mail list logo
