I just now managed to get a successful build of staden 1.4.1 on gentoo. I'm planning to make a gentoo ebuild so that anybody running gentoo can build staden from scratch. There are a couple things that have vexed me while getting the build going which make me think that maybe I didn't read some doc or do some other important thing.
For example, some of the tools staden has in its directory are written in perl and the she-bang at the top says perl should be in /usr/local/bin/perl. But redhat (and gentoo) installs perl to /usr/bin/perl by default.
Also, the .texi files have lines that look like:
These weren't building for me because there was no pregap4.txt hanging around (according to the makeinfo docs at gnu.org that is what makeinfo looks for if no extension is specified). I assumed that the .eps images were the ones desired (TeX style) and fixed the exercise1.texi (et al) as appropriate.
Many of the programs were not building because they needed libraries like -lread or -lmisc in there for the final link. So I went in to the makefile and added $(LIBIO_LIB) and the like.
It took all day but I finally have a build with success, but I can't shake the feeling that I worked hard instead of smart. How have others managed to get past these issues and build staden? What did I miss?
The build system IS a mess. I apologise for it, but it was never really intended to be used by others. One day perhaps we'll get it tidied up. It's far from trivial though to come up with a set of makefiles that work (with help) on such a diverse set of platforms.
The pregap4.txt (for example) texinfo issue is a new one to me. I've never seen it complain about this before. Yes Texinfo technically needs such files for producing the text "info" versions, but we do not use this output format.
Finally all the link lines should be valid. The code (well, 2003 at least anyway) has been built on both macosx and windows, both of which are absolutely adamant in having all symbols resolved even for when building dynamic libraries (ie dlls).
It's possible that you're seeing some odd linker behaviour. On one system I noticed that linking dynamic library B against dynamic library A meant that application C linked against B also needed to have an explicit link against library A. That is plain and simply wrong, but was needed to solve some odd "versioning" bug.
Hi James, I have put up a page, with a patch file, that looks like it gets staden building on my gentoo linux system. I also have a table of the problems I had building and how I solved them. The page is at http://www.cybertory.org/~jburks/staden.html
If anybody is having trouble building staden on linux, you might want to browse that page and see if it helps you get past the build problems.
Most of these changes are now in the CVS tree, with a few changes here and there.
The @image problem and makeinfo has been worked around. I no longer use makeinfo (it was only to expand up a couple of macros) as I rewrote the macros using m4. The extended syntax for @image didn't work on the standard makeinfo supplied in RedHat9, so I am guessing it is a sufficiently recent change that others would suffer the same problem.
The libraries woes I have not yet solved. These do not happen for me and I am now suspicious that it is a linker bug in gentoo.
My logic is that libtk_utils links against libread.so and libmisc.so when it is built. stash is an application that does not directly call anything within libmisc or libread. It links against libtk_utils.so and so any dependencies that tk_utils has on read/misc should be automatically resolved by the linker. Apparently they are not.
I cannot see how this can be anything except a linker bug. Any offers anyone?
For now I'm ignoring the problem, but ideally I would like to find a better solution to the problem. What is causing the linker to behave oddly for only this library? Is there a better way it can be fixed? Eg via linker options when building libtk_utils itself.
It is not inconceivable that the problem lies with gentoo. It may also be that I'm using gcc 3.3.3 instead of 3.2. Reading the error it gives suggests that gcc realizes it may not be a problem but recognizes that one library is dynamically linked against another (gives a warning that read is needed by tk_utils or something of that nature). GCC then flags the error when it finds a function it needs not in one of the specifically included libraries.
It is probably okay to ignore the linker issues for now, but if you see it show up when a GCC upgrade comes along (I got RedHat's end-of-life statement in email for RH9 the other day) it should be readily fixable.
I'll work at adding in these changes into the cvs tree, where easily doable.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.