Hi Ralf, On Mon, Mar 15, 2010 at 23:37, Ralf Wildenhues <ralf.wildenh...@gmx.de> wrote: > libtool also uses 'ar' in a number of places and cases, most > prominently, but not limited to, the static linking scenario. > Do you have measures in place to use 'D' there too?
Yes. At least in all the places I've noticed (or that are relevant for a Linux / ELF build), libtool actually uses $AR. Likewise with $RANLIB. If you want a repeatable build that avoids ar timestamps, you need: AR=... wrapper script that adds 'D' and strips 'u' from ar's first arg ... RANLIB=/bin/true or wrapper script that invokes /bin/true. (i didn't grep through all of the libtool code, but AFAICT at least ltmain.sh uses $AR and $RANLIB in preference to hard-coding ar and ranlib ... which makes sense, since, for example, it's gotta be cross-compilation friendly.) > IIRC some (non-GNU) compilers (or the assemblers they call, I don't > recall) also add time stamps to generated objects. Are they relevant to > you? I'm not sure whether one can turn stamps off everywhere; have you > looked into normalizing output like in GCC's contrib/compare-debug? In my experience, it's the object formats. E.g., COFF objects (including ECOFF and PE) include a timestamp. Looks like BFD puts in 0 for that in most cases, but e.g. the bfd/peXXigen.c code looks like it *will* generate a timestamp. Those object file formats are not relevant to me, though i've seen environments before were they're overridden. (I once wrote a small set of tools to do a timestamp-insensitive compare for windows builds. I've thankfully been *mostly* COFF-free for the past 10+ years. 8-) (BTW, my purpose isn't to be able to compare output files so much as create bit-identical output files. There are several reasons for this, but in summary, comparison isn't quite good enough. In order to do this, you've gotta do a bunch of other things, e.g., build with the same paths, use -frandom-seed appropriately if building some C++ code, ...) > Then, it would be nice to be able to confirm that we produce stable > output in cases where this is desirable; IOW, have testsuite exposure. > Can you describe your setup in a bit more detail? (You could also > provide a test case, but that will probably require copyright papers > then first.) Actually, my employer has a blanket assignment AFAIU, so that's not a problem. My test case is a GCC build, built on three different host system types (Ubuntu Dapper, Ubuntu Hardy, and Ubuntu pre-Lucid). libstdc++ is big enough and the filesystems different enough w.r.t. 'find' behavior that I get different orders on different systems. Not an easily-rolled-up test case. 8-) The problem with writing a test case is that find's traversal order is not guaranteed. It depends on a whole bunch of things, but most especially the implementation of readdir (or whatever similar interface it uses to read dir entries -- I haven't looked inside of GNU find ... maybe ever 8-), which often depends on the underlying file system. e.g., on my (Hardy) workstation: # /tmp is on the ext3 root file system: [...@cgda v14]$ mkdir /tmp/a [...@cgda v14]$ touch /tmp/a/a.o [...@cgda v14]$ touch /tmp/a/b.o [...@cgda v14]$ mkdir /tmp/b [...@cgda v14]$ touch /tmp/b/b.o [...@cgda v14]$ touch /tmp/b/a.o [...@cgda v14]$ find /tmp/a /tmp/a /tmp/a/a.o /tmp/a/b.o [...@cgda v14]$ find /tmp/b /tmp/b /tmp/b/a.o /tmp/b/b.o # ~/tmp is on NFs. [...@cgda v14]$ mkdir ~/tmp/a ~/tmp/b [...@cgda v14]$ touch ~/tmp/a/a.o [...@cgda v14]$ touch ~/tmp/a/b.o [...@cgda v14]$ touch ~/tmp/b/b.o [...@cgda v14]$ touch ~/tmp/b/a.o [...@cgda v14]$ find ~/tmp/a /home/cgd/tmp/a /home/cgd/tmp/a/a.o /home/cgd/tmp/a/b.o [...@cgda v14]$ find ~/tmp/b /home/cgd/tmp/b /home/cgd/tmp/b/b.o /home/cgd/tmp/b/a.o (Note how in /tmp, things came out in a consistent order, and in ~/tmp things came out in the order that they were created.) This makes it harder to make a test case where you're *sure* that the test is actually effective. Probably the easiest test likely to expose the problem would be... * create an archive (normal or libtool, I don't know what ltmain's func_extract_archive wants to operate on) with members b.o and a.o (in that order) * convince ltmain to generate a new archive including them then verify that the new archive has them in the order a.o and b.o. but obviously that wouldn't actually test anything in many circumstances (e.g., my /tmp example above). (AFAICT it doesn't look like libtool ever has to deal with indexless/ancient-BSD archives, where you had to use lorder|tsort to order the archive members... that's good because that would make the test a lot more difficult. 8-) Unfortunately, to be honest... I don't really have a clue about how to implement a test case like this. I've never actually attempted to use libtool to do anything (e.g., create archives)... Also complicating the issue is that I really don't know think one about libtool, e.g., how to make it do what I want in this case. Getting a working testcase out of me is going to be ... difficult. 8-) chris
