Version: (using KDE Devel) Installed from: Compiled sources Compiler: GCC 3.3 OS: Linux This occurs with both 3.1.3 and recent CVS. I have found that extracting the 0.6.2_3 version of my program source from it's tar.gz [http://www.methylblue.com/filelight/filelight-0.6.2_3.tar.gz] with the KIO slave will give a set of sources that will not link. I have also received a similar error from one other user. However extracting the same sources with gtar or Ark results in a set of sources that link perfectly. The exact series of events follow: I opened the tar.gz by clicking on it in Konqueror to give the virtual root folder for the archive. I extracted by dragging the folder to the desktop and selecting copy, all files were extracted except the zero-byte stamp.h.in file (a separate bug perhaps?). Configure ran fine, make caused configure to run again. Failure occurred after a few sources had compiled on linking the error messages are attached (VTT and vtable complaints) I tried ./configure && make with the Ark extracted archive (Ark extracted all the files). Configure ran only once and make completed fine with no errors. I ran a diff of the two directories before and after the compile. Before the only difference was the absence of the stamp.h.in file, afterwards there werre many differences although I don't understand them.
Created attachment 2491 [details] KIO Tar Link Errors
Created attachment 2492 [details] The diff between the two directories after building If you need me to test anything else, I'd be happy to.
Subject: Re: Can't Link Extracted Sources On Wednesday 17 September 2003 22:05, you wrote: > If you need me to test anything else, I'd be happy to. This is very hard to figure out. The vtable problems are moc files not generated, and this means am_edit didn't run.... > all files were extracted except the zero-byte stamp.h.in file (a separate bug perhaps?) This could be the reason. The only other reason could be timestamp problems. Can you try extracting the tar.gz normally (with tar), removing stamp.h.in, and see if you get the same problems? Then we know the only bug is the empty file not extracted (I'll look into that one)
Hi, extracting with tar and removing stamp.h.in did not stop the build, ie. it built fine. However I found that if I copy the extracted archive that the tar slave generated, it will then build. So I tried running find -exec touch "{}" ";" on a slave generated extraction and that also built. I re-checked that a normal slave extraction wouldn't build; it wouldn't. Ark and tar both extracted the files from the archive with today's timestamps, while the tar slave, as I'm sure you know, extracted them with the dates they were stamped in the archive. So is the problem a bug with my scripts/Makefiles? If so KDevelop 2.1 generated those. A quick look at my working sources and the archive show the dates for the auto* stuff are the same (I didn't look in intricate detail) so it seems strange that one would build and not the other. Anyway, I await your advice.
I can reproduce the problem with the current CVS. However, when I replace the admin directory with the one from current CVS and everything links fine. I think we can asume that this problem is unrelated to the ioslave, it's probably the build system that borks on older dates. Please check the problem again by packing up the sources with the new admin directory and untarring that one with the ioslave. It works for me, I just want to know if it works for you. Niels.
Can somebody still re-produce such a behaviour? (The source tarball is not available anymore). (And if you do please try to find the difference just after extracting, before calling anything of the build system. We must really see if it is a date problem or a rare extraction problem.) Have a nice day!
Yeah, the described steps for building filelight work fine for the most recent (1.0-beta6) tarball. So presumably it was a build system issue which was affected by the preserved timestamps when using the kio slave. Sorry for the noise, thanks for the product. :-)
I suppose that this bug is a duplicate of bug #58950 (where unfortunately the extracting put file stamps in an order that brought a failure.) *** This bug has been marked as a duplicate of 58950 ***