Getting around smartmontools linker errors

I posted a blog entry a while back that showed how to setup smartd on a Solaris system. Two individuals left comments indicating that smartmontools wouldn’t build, and one individual (Peter) received the following errors during the build process:

gcc  -g -O2 -Wall -W -c `test -f 'os_solaris_ata.s' || echo './'`os_solaris_ata.s
gcc  -g -O2 -Wall -W   -o smartd  smartd.o atacmdnames.o  atacmds.o ataprint.o knowndrives.o scsicmds.o scsiprint.o utility.o o
s_solaris.o os_solaris_ata.o -lnsl
ld: fatal: relocation error: R_SPARC_32: file os_solaris_ata.o: symbol : offset 0xfea5feef is non-aligned
ld: fatal: relocation error: R_SPARC_32: file os_solaris_ata.o: symbol : offset 0xfea5fef5 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file os_solaris_ata.o: symbol : offset 0xfea5fef9 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file os_solaris_ata.o: symbol : offset 0xfea5fefd is non-aligned
ld: fatal: relocation error: R_SPARC_32: file os_solaris_ata.o: symbol : offset 0xfea72806 is non-aligned
ld: fatal: relocation error: R_SPARC_32: file os_solaris_ata.o: symbol : offset 0xfea77436 is non-aligned
collect2: ld returned 1 exit status

I was able to recreate the problem on my Sun Ultra 10 running Solaris 10. To get smartmontools to compile, I ran “configure,” “make,” and then waited for the build process to fail. Once the build errored out, I removed the “-g” option from the gcc options and executed the following statements by hand:

$ gcc -O2 -Wall -W -c `test -f ‘os_solaris_ata.s’ || echo ‘./’`os_solaris_ata.s

$ make

Since os_solaris_ata.s is a hand coded SPARC assembly file, I am not 100% certain why the smartmontools authors are trying to add debugging symbols to the object file. I will need to do some additional digging to find the answer.

5 Comments

Frank  on April 28th, 2006

Thanks for the tip. I have some in-house software with the same problem, using Solaris CC it works. In my case, it was obvious that it’s -g from the error.

Also, gnupg has this problem due to assembly in the mpi lib. I fixed it the same way.

If you uncover any more details on this problem, I’m very interested to find out about it.

Frank  on May 2nd, 2006

> I fixed it the same way.

Actually, come to think of it, I fixed it by using -gstabs (for the entire software package, not just the asm files that have problems). This at least gives some debugging info.

Anyway, I found the root cause of the problem. http://sources.redhat.com/bugzilla/show_bug.cgi?id=144

Rainer  on May 13th, 2006

Frank,

can you bee a little more verbose, pleeeaaase?
I have exactly this problem with building gnupg-1.4.3, using gcc 3.4.3. And I’m not a programmer at all :-(

Rainer

Dalibor Topic  on February 14th, 2007

Thanks, setting CFLAGS=-gstabs+ fixed the gpg 1.4.6 build for me, as well.

Jim  on March 27th, 2009

Thank, you! Thank, you! I spent an entire day trying to figure out why I couldn’t successfully build qpopper on a Solaris system (for anyone else encountering see Qpopper 4.0.16 Upgrade on a Solaris 5.7 System . Using ./configure CFLAGS=gstabs+ allowed me to successfully compile the software and move on to other overdue work.

Leave a Comment