The Old Joel on Software Forum: Part 3 (of 5)

UNIX strangeness

Hello,

Im sorry if this is completely OT, but I have a strange error when compiling mcrypt for Solaris, and have been googling but Im unable to find pointers to this error.

The error I get is

ld: elf error: file functions.o: elf_strptr: Request error: no string table

Anybody seen this, and can give some pointers to solutions, that would be very much appreciated.

<--- more complete sceen dump --->

gcc -g -O2 -I/usr/local/include -Wall -s -o mcrypt extra.o mcrypt.o keys.o random.o rndunix.o xmalloc.o functions.o errors.o bits.o openpgp.o rndwin32.o environ.o getpass.o ufc_crypt.o popen.o classic.o rfc2440.o gaaout.o -lz /usr/local/lib/libmhash.so -L/usr/local/lib /usr/local/lib/libmcrypt.so -R/usr/local/lib -R/usr/local/lib
ld: elf error: file functions.o: elf_strptr: Request error: no string table
ld: elf error: file classic.o: elf_strptr: Request error: no string table
ld: fatal: File processing errors. No output written to mcrypt
collect2: ld returned 1 exit status

Thank you

Patrik
Tuesday, January 20, 2004

God, Im stupid.

Im sorry to waste your time. Problem solved.

What happened was I ran out of diskspace during one build, and then fixed that problem, however I did not do a 'make clean' before starting over, so I guess some files was bad from the previous make. So when linking the different .o - files I ran into the above error.

When I started over fresh, after a make clean it worked.

Patrik
Tuesday, January 20, 2004

Wouldn't it be useful if we had a magic whiteboard that displays the standard courses of action we should first take when we have a problem.

You start muttering it's not compiling, it displays 'make clean'

You start muttering about how someones changes broke your build, it displays 'cvs update'

You start muttering about how your changes don't seem to be doing anything, it displays 'check the code is saved'

Colin Newell
Tuesday, January 20, 2004

Colin,

Point taken :-)

Patrik
Tuesday, January 20, 2004

That wasn't a dig at you, just something I know I'd find useful ;)

Colin Newell
Tuesday, January 20, 2004

"You start muttering about how someones changes broke your build, it displays 'cvs update'"

<rant>
I've had situations where someone was 'Improving' the globaly shared libraries and include files while other team members were developing. The result was that when you compiled your changes to test, the build would break because 98% of your object files were expecting the old version, and the 2% you just built have the new version
(plus there would be some code changes checked in).

So the cycle became:
1) Build break
2) Check that it wasn't my code that caused the break
3) make clean
4) cvs update
5) make all
6) let the build run for 1-2 hours, and try to find something else to do in the mean time.

Of course everyone else had the same problem too, and that slowed down the build time even more as the network screamed in agony. And you had a good chance of the shared libraries and include files being updated again in the middle of your compile, and you would have to start the whole process over again.

There were days people spent all day compiling, trying to get to the point that they could actually do some development work.

Lesson: go ahead, do developement work on your libraries during the day; however, changes to globaly shared libraries and include files should only be released into the wild after hours, when the nightly builds can take care of those problems.
</rant>

DoesUnixMakeYouAEunuch
Tuesday, January 20, 2004

You can prevent this problem in the future by changing the way you compile. Instead of doing something like this:

$(CC) $(CFLAGS) -c $< -o $@

Do it like this:

$(CC) $(CFLAGS) -c $< -o $@.new
mv $@.new $@

That way, any problem, including a disk-full error, will prevent the .o file from being created. After you free up some disk space, make will automatically rebuild the .o file without you needing to "make clean".

rob mayoff
Tuesday, January 20, 2004

SCons solves all that, and much much more.
[ http://scons.sourceforge.net ]

Ori Berger
Wednesday, January 21, 2004

That is frustrating, but the most common problem I found was the head of a team consistently whining every morning. An hour later of arguing (with whomever he had blamed for breaking the build) he would be convinced to do an update and shock horror! It fixed his build!

Colin Newell
Wednesday, January 21, 2004

"An hour later of arguing (with whomever he had blamed for breaking the build) he would be convinced to do an update and shock horror! It fixed his build!"

Only because the sneaky devs fixed the problem in the meantime.

Wednesday, January 21, 2004