>> The latest public release of elftoolchain, elftoolchain-0.6.1, has a >> bug in that it does not process DWARF4 correctly; get it as follows: > > Right now elftoolchain is still a reasonably fast-moving target, so > using a source snapshot is likely to be preferable for the near > future. I don't see this as a workaround, but rather a natural > consequence of elftoolchain's current stage of development.
Ok, but at least do a 0.6.2 release that at least includes this fix to a major bug. That is, do bug fix releases when show-stopper bugs are fixed so that the public release is at least not *known* to be buggy. Or just don't do public releases at all and tell people to get the latest version from svn; I do this on some projects. >> The build process will stop and tell you to do this if you do not do >> it initially: >> >> Please download the distribution from: >> >> http://tetworks.opengroup.org/downloads/38/software/Sources/3.8/tet3.8-src.\ >> tar.gz >> and unpack it into directory "../../test/tet/tet3.8". >> >> The tet3.8-src.tar.gz file unpacks into a dir named tet3.8 and the >> message above means to put it into elftoolchain-0.6.1/test/tet/. > > This could be automated, but doesn't seem like a big hurdle to me, and > a number of other projects handle third-party dependencies in a > similar way. I think some test suite rework might be planned and > perhaps this can be addressed then. People are in the habit of setting up a build and then walking away and expecting to come back to a finished build. If you don't do this, the build process goes on for quite a while and then stops saying to install the above-mentioned code. That's really annoying. Instead, look for the dependency up front and if it is missing, tell the user right away. >> There does not seem to be a configure step. Note that when building >> on Linux, the instructions are wrong: just using pmake will not work, >> you must invoke it as follows: >> >> $ NOGCCERROR=1 pmake > > What errors do you see if you do not? Some warning that turns into a build error; I can't recall as it has been a while. However it was a *lot* of work to figure this out: grepping around through files here and there. This is the kind of thing that will stop most people, so if you want to increase adoption, just fixing this one point could make a major difference. >> You must install elftoolchain in order to build against it; it is not >> enough to just use +-I+ and +-L+ flags as the internal headers within >> elftoolchain will not find each other. > > The tools provided with elftoolchain (nm, size, etc.) do build against > the just-built libelf and libdwarf, so it is certainly possible. What > command line did you try, and what error did you see? Again, I have not tried it for a while, so I no longer recall exactly, but I tried using -I and -L in the obvious ways and some of your internal includes didn't find each other. If the "install in a local non-default directory" instructions from INSTALL work, then that provides a way for people to build but not override the default install. Another major bug is using the name libdwarf when a libdwarf project already exists which you are explicitly imitating: you are basically violating his trademark. Firebird changed their name to Firefox just because another project existed. Daniel ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk _______________________________________________ Elftoolchain-developers mailing list Elftoolchain-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/elftoolchain-developers
