Build environment bug: 675125
 

Hi,

I've an interesting problem: bug #675125.
Its a grave bug against slang2, as it breaks jed, (and other things).
slang2-2.2.14-12+ (in sid) breaks jed for certain locales (C is broken,
*.UTF-8 look fine);
but slang2_2.2.14-10 (in testing) looks fine.

The trouble is, while downgrading to -10 fixes issues, _rebuilding_ -10
in sid results in a
broken libslang2 ; i.e. the problem is not the slang2 package, but the
build environment.
So far i've tested with ncurses, locale from testing but haven't found
the cause yet.

While i'm still investigating, _something_ in the sid environment is the
real culprit and
I can't assign a bug to it yet until I pin it down. Has anyone seen a
similar issue elsewhere,
or got a hint as to how to handle it? I want to make sure we don't just
freeze on the current slang but ship the
broken environment.

best regards
Alastair

--
Alastair McKinstry , <alastair@sceal.ie> , <mckinstry@debian.org> http://blog.sceal.ie

Anyone who believes exponential growth can go on forever in a finite world
is either a madman or an economist - Kenneth Boulter, Economist.



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4FE08A9B.4090007@debian.org">http://lists.debian.org/4FE08A9B.4090007@debian.org

Build environment bug: 675125
 

Hi,


> I've an interesting problem: bug #675125.
> Its a grave bug against slang2, as it breaks jed, (and other things).
> slang2-2.2.14-12+ (in sid) breaks jed for certain locales (C is broken,
> *.UTF-8 look fine);
> but slang2_2.2.14-10 (in testing) looks fine.
>
> The trouble is, while downgrading to -10 fixes issues, _rebuilding_ -10
> in sid results in a
> broken libslang2 ; i.e. the problem is not the slang2 package, but the
> build environment.
> So far i've tested with ncurses, locale from testing but haven't found
> the cause yet.
>
> While i'm still investigating, _something_ in the sid environment is the
> real culprit and
> I can't assign a bug to it yet until I pin it down. Has anyone seen a
> similar issue elsewhere,
> or got a hint as to how to handle it? I want to make sure we don't just
> freeze on the current slang but ship the
> broken environment.

Try gcc/g++ 4.6 instead of 4.7. Maybe check if "S-Lang load path" (wherever that
is stored) is initialized in a sane way. I had a similar issue where an integer
was 0 all the time - although not being initialized with something useful -
which changed with gcc 4.7, then it was just a random value :)


--
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4FE0E915.1090305@bzed.de">http://lists.debian.org/4FE0E915.1090305@bzed.de

Build environment bug: 675125
 

Hello,

On Tue, 19 Jun 2012 23:03:17 +0200
Bernd Zeimetz <bernd@bzed.de> wrote:

> Try gcc/g++ 4.6 instead of 4.7. Maybe check if "S-Lang load
> path" (wherever that is stored) is initialized in a sane way. I had a
> similar issue where an integer was 0 all the time - although not
> being initialized with something useful - which changed with gcc 4.7,
> then it was just a random value :)

By the way, it might be a good idea to fill .bss section with random
values intentionally for debug builds to detect non-properly-initialised
things more effectively :)

--
WBR, Andrew

Build environment bug: 675125
 

Andrew Shadura wrote:
> By the way, it might be a good idea to fill .bss section with random
> values intentionally for debug builds to detect non-properly-initialised
> things more effectively :)

Variables in the .bss section will by definition get initialized to 0.
For example, a C variable defined as "static typename varname;" must get
initialized to 0, and the compiler and linker will stick it in the .bss
section expecting that it will end up with a value of 0 at runtime.
That represents a defined property of the standard, not an
implementation quirk. So, the .bss section must get initialized to 0,
not to random values, whether in a debug build or not.

- Josh Triplett


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120619221131.GA27346@leaf

Build environment bug: 675125
 

Hello,

On Tue, 19 Jun 2012 15:11:33 -0700
Josh Triplett <josh@joshtriplett.org> wrote:

> Variables in the .bss section will by definition get initialized to 0.
> For example, a C variable defined as "static typename varname;" must
> get initialized to 0, and the compiler and linker will stick it in
> the .bss section expecting that it will end up with a value of 0 at
> runtime. That represents a defined property of the standard, not an
> implementation quirk. So, the .bss section must get initialized to 0,
> not to random values, whether in a debug build or not.

Oh, yes, indeed, though I see no such requirement to put initialise
non-static variables in the standard, so static variables could just go
to .data section, leaving .bss truly uninitialised.

--
WBR, Andrew

Build environment bug: 675125
 

Le 19/06/2012 16:20, Alastair McKinstry a écrit :
> While i'm still investigating, _something_ in the sid environment is the
> real culprit and
> I can't assign a bug to it yet until I pin it down. Has anyone seen a
> similar issue elsewhere,
> or got a hint as to how to handle it? I want to make sure we don't just
> freeze on the current slang but ship the
> broken environment.

A hint: snapshot.debian.org.


Cheers,

--
Stéphane


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4FE16530.2020301@debian.org">http://lists.debian.org/4FE16530.2020301@debian.org