FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian GCC

 
 
LinkBack Thread Tools
 
Old 01-28-2009, 09:28 PM
"J.H.M. Dassen (Ray)"
 
Default Bug#513420: Breaks building libgsf from source

Package: gcc-4.3
Version: 4.3.3-1
Severity: serious
Justification: causes libgsf to no longer build from source; regression
compared to testing's gcc-4.3 packages.

What am I trying to do:
* Build libgsf from source again on amd64 (or build libgsf svn trunk).

How am I trying to do it / steps to reproduce:
* Set up a sid environment in which to build libgsf from the Debian source
package, e.g. in pbuilder.
* Get the libgsf source package and extract it.
* In the source directory, run
env MALLOC_CHECK_=2 debian/rules build

What behaviour did I expect to get:
* The libgsf build runs to completion.

What behaviour did I actually get:
* The libgsf build fails during documentation generation, with messages
similar to the following:
creating gsf-scan
gtk-doc: Running scanner gsf-scan
sh: line 1: 27898 Segmentation fault ( ./gsf-scan )
Scan failed:
make[3]: *** [scan-build.stamp] Error 139
make[3]: Leaving directory `/tmp/buildd/libgsf-1.14.11/build/doc'
* This behaviour is fully repeatable for me.

Notes and observations:
* "gsf-scan" is built from generated sources using gtk-doc-tools.
* To preserve the gsf-scan sources and objects, comment out the unlink line
which removes them in /usr/bin/gtkdoc-scangobj .
* When running plain "debian/rules build" without the env MALLOC_CHECK_=2,
the problem manifests at a later point in the build as follows:
cd ../../doc/html && gtkdoc-mkhtml gsf ../gsf-docs.sgml
../xml/text.xml:255: parser error : Input is not proper UTF-8, indicate encoding !
Bytes: 0xD0 0x45 0x2E 0x02
<para>When to quote fields.</para><para>Default value: ĞE.</para>
^
../xml/text.xml:255: parser error : PCDATA invalid Char value 2
<para>When to quote fields.</para><para>Default value: ĞE.</para>
^
../xml/text.xml:279: parser error : chunk is not well balanced

^
../gsf-docs.sgml:232: parser error : Failure to process entity GsfText
&GsfText;
^
../gsf-docs.sgml:232: parser error : Entity 'GsfText' not defined
&GsfText;
^
unable to parse ../gsf-docs.sgml
make[3]: *** [html-build.stamp] Error 6
This can be tracked back to a garbage string in the <DEFAULT> block within
the <ARG> block for GsfOutputCsvQuotingMode in doc/gsf.args which is a
file generated by gsf-scan. The garbage string can vary between repeated
attempts.
* This libgsf version (1.14.11-1) has previously been built successfully on
all architectures.
* The problem is still reproducible for me when the optimisation level is
reduced (in debian/rules) to -O1 .
* I could not reproduce the problem in the following variations:
* When lowering the optimisation level to -O0 .
* Building in a 32-bit pbuilder chroot on amd64.
* Building in a sid environment with the gcc-4.3 packages downgraded to
the 4.3.2-1.1 versions from testing.
* Building using CC=gcc-4.2 .
* Building using CC=gcc-4.1 .
* Building using CC=/usr/lib/gcc-snapshot/bin/gcc .
which makes me suspect that the problem isn't with the (generated)
gsf-scan sources, but with gcc's code generation.

-- System Information:
Debian Release: 5.0
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'testing-proposed-updates'), (500, 'stable'), (400, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.28.2 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages gcc-4.3 depends on:
ii binutils 2.18.1~cvs20080103-7 The GNU assembler, linker and bina
ii cpp-4.3 4.3.3-1 The GNU C preprocessor
ii gcc-4.3-base 4.3.3-1 The GNU Compiler Collection (base
ii libc6 2.7-18 GNU C Library: Shared libraries
ii libgcc1 1:4.3.3-1 GCC support library
ii libgomp1 4.3.3-1 GCC OpenMP (GOMP) support library

Versions of packages gcc-4.3 recommends:
ii libc6-dev 2.7-18 GNU C Library: Development Librari

Versions of packages gcc-4.3 suggests:
ii gcc-4.3-doc 4.3.2.nf1-1 documentation for the GNU compiler
pn gcc-4.3-locales <none> (no description available)
ii gcc-4.3-multilib 4.3.3-1 The GNU C compiler (multilib files
pn libgcc1-dbg <none> (no description available)
pn libgomp1-dbg <none> (no description available)
pn libmudflap0-4.3-dev <none> (no description available)
pn libmudflap0-dbg <none> (no description available)

-- no debconf information



--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-29-2009, 01:55 AM
Steve Cotton
 
Default Bug#513420: Breaks building libgsf from source

Hi Ray,

I've spent a while looking at what runs what, and realised that it
will be quite time consuming for someone not familiar with your
package to extact a test case. Would it be possible for you to
isolate the gsf-scan bit; and provide the arguments and input
files to run it in isolation rather than running a framework that
runs it?

Also, most of the calls to cc are using -Wno-sign-compare
-Wno-pointer-sign , and redirecting all output to /dev/null .

Steve

--
I laugh at the dangers of saying in IRC that I'll take care of a bug when
it's not yet too late in the morning.
-- me, about two hours ago



--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-29-2009, 05:05 AM
Matthias Klose
 
Default Bug#513420: Breaks building libgsf from source

forwarded 513420 http://gcc.gnu.org/PR39015
tag 513420 + upstream
tag 513420 + pending
thanks

preparing 4.3.3-3.

caused by the fix for PR38615. would it be possible to track down the
miscompiled source file and update the upstream report?

J.H.M. Dassen (Ray) schrieb:
> Package: gcc-4.3
> Version: 4.3.3-1
> Severity: serious
> Justification: causes libgsf to no longer build from source; regression
> compared to testing's gcc-4.3 packages.




--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-29-2009, 09:02 AM
"J.H.M. Dassen (Ray)"
 
Default Bug#513420: Breaks building libgsf from source

On Thu, Jan 29, 2009 at 02:55:20 +0000, Steve Cotton wrote:
> I've spent a while looking at what runs what, and realised that it will be
> quite time consuming for someone not familiar with your package to extact
> a test case.
>
> Would it be possible for you to isolate the gsf-scan bit;

.c and .i are now attached to PR39015.

> and provide the arguments and input files to run it in isolation
> rather than running a framework that runs it?

gsf-scan, once generated, is more or less standalone; it is run without
arguments and does not rely on any input files, but it is linked against
libgsf itself.

> Also, most of the calls to cc are using -Wno-sign-compare
> -Wno-pointer-sign , and redirecting all output to /dev/null .

Actually, it's -Wno-sign-compare ... -Wsign-compare. The "no" comes from
GNOME_COMPILE_WARNINGS; the override is done explicitly in configure.in .
The output redirection, well¸ that's libtool for you...

Let me know if you need anything further.

HTH,
Ray
--
Gartner Group ?!? Never heard of them. What did they do in computing
except manage to put on their tie without accidentaly killing themselves ?!?
Mark Veltzer explains the value of industry analysts in
http://linuxtoday.com/news_story.php3?ltsn=2001-06-21-006-21-NW-EL-MR



--
To UNSUBSCRIBE, email to debian-gcc-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 06:59 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org