headers
Koen van der Drift | 1 Mar 2007 03:24
Picon
Favicon
Gravatar

Re: gcc42 O0g.gch: file changed as we read it (again)

I am also having issues with building gcc:

...
/usr/bin/install -d -m 700 /sw/src/fink.build/root-gcc4- 
shlibs-4.1.9999-20060617/sw/share/doc/gcc4-shlibs
/bin/cp -r gcc/COPYING /sw/src/fink.build/root-gcc4- 
shlibs-4.1.9999-20060617/sw/share/doc/gcc4-shlibs/
/bin/cp -r gcc/COPYING.LIB /sw/src/fink.build/root-gcc4- 
shlibs-4.1.9999-20060617/sw/share/doc/gcc4-shlibs/
/bin/chmod -R go=u-w /sw/src/fink.build/root-gcc4- 
shlibs-4.1.9999-20060617/sw/share/doc/gcc4-shlibs
/bin/rm -f /sw/src/fink.build/root-gcc4-shlibs-4.1.9999-20060617/sw/ 
info/dir /sw/src/fink.build/root-gcc4-shlibs-4.1.9999-20060617/sw/ 
info/dir.old /sw/src/fink.build/root-gcc4-shlibs-4.1.9999-20060617/sw/ 
share/info/dir /sw/src/fink.build/root-gcc4-shlibs-4.1.9999-20060617/ 
sw/share/info/dir.old
Writing control file...
Writing package script postinst...
Writing package script prerm...
dpkg-deb -b root-gcc4-4.1.9999-20060617 /sw/fink/10.4/unstable/main/ 
binary-darwin-powerpc/languages
dpkg-deb: building package `gcc4' in `/sw/fink/10.4/unstable/main/ 
binary-darwin-powerpc/languages/gcc4_4.1.9999-20060617_darwin- 
powerpc.deb'.
tar: ./sw/lib/gcc4/include/c++/4.2.0/powerpc-apple-darwin8/bits/stdc+ 
+.h.gch/O0g.gch: file changed as we read it
/sw/bin/dpkg-deb: subprocess tar -cf returned error exit status 1
### execution of dpkg-deb failed, exit code 2
Removing runtime build-lock...
Removing build-lock package...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Macks | 1 Mar 2007 08:38

Re: libart2-2.3.18 chokes on C++

On Wed, Feb 28, 2007 at 07:41:43PM +0100, Martin Costabel wrote:
> The bug is in libart_lgpl/art_misc.h. The function declarations
> 
> void *art_alloc(size_t size);
> void art_free(void *ptr);
> void *art_realloc(void *ptr, size_t size);
> 
> need to be enclosed in 'extern "C"', just like the later declarations of 
>   art_die() etc are.
> 
> If someone has contact to the upstream developers, please tell them.

Fixed in fink (along with quick version), and filed upstream.

Thanks for the diagnosis and treatment!

dan

--

-- 
Daniel Macks
dmacks <at> netspace.org
http://www.netspace.org/~dmacks

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Permalink | Reply | 1 comment |
headers
Martin Costabel | 1 Mar 2007 08:56
Picon

Re: libart2-2.3.18 chokes on C++

Daniel Macks wrote:
[]
> Fixed in fink (along with quick version), and filed upstream.

Thanks a lot. I am curious if they'll wake up enough to fix this...

--

-- 
Martin

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Permalink | Reply | 0 comments |
headers
Jean-François Mertens | 2 Mar 2007 04:20
Picon
Favicon

Re: gcc42 O0g.gch: file changed as we read it (again)


On 27 Feb 2007, at 18:44, Daniel Johnson wrote:

> I don't know exactly why it's happening, but I have figured out some
> things. The "file changed as we read it" warning does occur sometimes
> with tar 1.15.1, but it always returned an exit code of 0 in such
> cases. It would return 1 if a fatal error occurred. Starting with
> 1.16, tar now returns 0 for success, 1 for non-fatal errors (like the
> file changed one) and 2 for fatal errors. The problem is that dpkg-
> deb fails if tar returns a non-zero exit code. Now dpkg-deb could be
> patched, but since you'd still want it to fail for truly fatal errors
> and the fatal error code changed from 1 to 2, it needs to know which
> version of tar it's using or Bad Things could happen.
Daniel,

For the moment, the  major problem seems to be in 10.4/unstable,
where we know the version of tar.
So why don't you go ahead and commit your patch to dpkg there _
(with if you want a versioned dep on tar).
I've no idea about the bootstrap process (just know it is not starting
with just symlinks in %p pointing to corresponding things in /usr,
and then building in strict build-order with '%i' silently substituted
by '%p' until dpkg is installed).
But I can't see how such a patch _ sorry: much better, correction _
of dpkg in that tree could have any negative impact, even on the
bootstrap process (and even if it was as I would have thought).
So please commit your correction to dpkg, unless someone
screams with good arguments in the next couple of hours ...

> Another bit of information is that the code in tar that checks if a
(Continue reading)

Permalink | Reply | 4 comments |
headers
Daniel Johnson | 2 Mar 2007 05:52

Re: gcc42 O0g.gch: file changed as we read it (again)


On Mar 1, 2007, at 10:20 PM, Jean-François Mertens wrote:

>
> On 27 Feb 2007, at 18:44, Daniel Johnson wrote:
>
>> I don't know exactly why it's happening, but I have figured out some
>> things. The "file changed as we read it" warning does occur sometimes
>> with tar 1.15.1, but it always returned an exit code of 0 in such
>> cases. It would return 1 if a fatal error occurred. Starting with
>> 1.16, tar now returns 0 for success, 1 for non-fatal errors (like the
>> file changed one) and 2 for fatal errors. The problem is that dpkg-
>> deb fails if tar returns a non-zero exit code. Now dpkg-deb could be
>> patched, but since you'd still want it to fail for truly fatal errors
>> and the fatal error code changed from 1 to 2, it needs to know which
>> version of tar it's using or Bad Things could happen.
> Daniel,
>
> For the moment, the  major problem seems to be in 10.4/unstable,
> where we know the version of tar.
> So why don't you go ahead and commit your patch to dpkg there _
> (with if you want a versioned dep on tar).
> I've no idea about the bootstrap process (just know it is not starting
> with just symlinks in %p pointing to corresponding things in /usr,
> and then building in strict build-order with '%i' silently substituted
> by '%p' until dpkg is installed).
> But I can't see how such a patch _ sorry: much better, correction _
> of dpkg in that tree could have any negative impact, even on the
> bootstrap process (and even if it was as I would have thought).
> So please commit your correction to dpkg, unless someone
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Costabel | 2 Mar 2007 07:36
Picon

Re: gcc42 O0g.gch: file changed as we read it (again)

Jean-François Mertens wrote:
[]
> (I would bet rather on the ctime than on the size _ which looks
> to me as an almost redundant test _, but evidence for that
> will disappear after your patch ..  (sigh)  )

I wonder why none of the people who are having this problem really tried 
to get to the bottom of it. It wouldn't be hard to create a "debugging" 
version of tar that prints out some more information when it makes dpkg 
crash, like old and new ctime and old and new size. This would allow us 
to see whether tar is detecting real problems or is just being hysterical.

--

-- 
Martin

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Permalink | Reply | 1 comment |
headers
Daniel Macks | 2 Mar 2007 07:59

Re: gcc42 O0g.gch: file changed as we read it (again)

On Fri, Mar 02, 2007 at 07:36:08AM +0100, Martin Costabel wrote:
> Jean-Fran?ois Mertens wrote:
> []
> > (I would bet rather on the ctime than on the size _ which looks
> > to me as an almost redundant test _, but evidence for that
> > will disappear after your patch ..  (sigh)  )
> 
> I wonder why none of the people who are having this problem really tried 
> to get to the bottom of it. It wouldn't be hard to create a "debugging" 
> version of tar that prints out some more information when it makes dpkg 
> crash, like old and new ctime and old and new size. This would allow us 
> to see whether tar is detecting real problems or is just being hysterical.

Here's an interesting comment from upstream (as part of a thread that
seems generally related):
  http://www.mail-archive.com/bug-tar <at> gnu.org/msg00991.html

dan

--

-- 
Daniel Macks
dmacks <at> netspace.org
http://www.netspace.org/~dmacks

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
(Continue reading)

Permalink | Reply | 0 comments |
headers
Max Horn | 2 Mar 2007 13:21
Picon
Gravatar

gtk+2 2.6 to stable?

Hi,

I was wondering: Is there any particular reason to *not* move gtk+2  
v2.6 to the stable tree (which currently still has 2.4.9) ? All its  
deps are in stable, according to a check done with
   fink --trees=stable,virtual rebuild gtk+
(after copying the 2.6 .info file to stable).

Cheers,
Max

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Permalink | Reply | 1 comment |
headers
Benjamin Reed | 2 Mar 2007 14:00
Gravatar

Re: gtk+2 2.6 to stable?


Max Horn wrote:
> Hi,
> 
> I was wondering: Is there any particular reason to *not* move gtk+2  
> v2.6 to the stable tree (which currently still has 2.4.9) ? All its  
> deps are in stable, according to a check done with
>    fink --trees=stable,virtual rebuild gtk+
> (after copying the 2.6 .info file to stable).

Hm, I think that would be a good idea...

Especially since if I ever get to finishing testing the pangocairo
branch, gtk+-related packages are going to really be shaken up in
unstable soon...

--
Benjamin Reed a.k.a. Ranger Rick
Fink, KDE, and Mac OS X development
http://www.racoonfink.com/
Permalink | Reply | 0 comments |
headers
Martin Costabel | 3 Mar 2007 09:52
Picon

Help with debugging mysterious tar error

Could those of you who have or had the dpkg-deb failure caused by 
tar-1.16.1 claiming

   "file changed as we read it"

please help with debugging this? Based on the outcome of these tests, we 
should be able to decide whether we need to patch tar or dpkg, or 
whether we need to dig further down.

I have made a special version of the tar executable that prints some 
more information if this error appears. It prints the old/new ctimes and 
the old/new file sizes. The special version is a universal binary (so it 
should work on both ppc and intel) and is available at 
http://perso.orange.fr/costabel/tar.gz

A possible test procedure to follow would be:

1. Download the new tar:

   curl -O http://perso.orange.fr/costabel/tar.gz
   gunzip tar.gz
   chmod +x tar
   mv tar /var/tmp/

2. Replace (temporarily) Fink's tar by the new one

   sudo ln -sf /var/tmp/tar /sw/bin/tar

3. Build one of the packages that give you the tar error (mysql, gcc42, 
gnumeric were among those where the error was reported). Cross your
(Continue reading)

Permalink | Reply | 19 comments |

Gmane