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 thoughts on “Getting around smartmontools linker errors”

  1. 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.

  2. 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

Leave a Reply

Your email address will not be published. Required fields are marked *