271317 - libswft.so linking problems ; needs DEF file

Status: VERIFIED FIXED

(NSS :: Libraries, defect, P1)

Description

[Julien Pierre]

I ran into a problem linking libswft.so on Solaris AMD64 using gcc .

The error message is :

gcc -m64 -shared -h libswft.so -o SunOS5.10_i86pc_gcc_64_OPT.OBJ/libswft.so
SunOS5.10_i86pc_gcc_64_OPT.OBJ/forsock.o
SunOS5.10_i86pc_gcc_64_OPT.OBJ/fortpk11.o
SunOS5.10_i86pc_gcc_64_OPT.OBJ/fmutex.o SunOS5.10_i86pc_gcc_64_OPT.OBJ/stub.o  
../../../../../../dist/SunOS5.10_i86pc_gcc_64_OPT.OBJ/lib/libswfci.a
../../../../../../dist/SunOS5.10_i86pc_gcc_64_OPT.OBJ/lib/libsoftokn.a
../../../../../../dist/SunOS5.10_i86pc_gcc_64_OPT.OBJ/lib/libfreebl.a 
../../../../../../dist/SunOS5.10_i86pc_gcc_64_OPT.OBJ/lib/libsecutil.a
../../../../../../dist/SunOS5.10_i86pc_gcc_64_OPT.OBJ/lib/libplc4.a
../../../../../../dist/SunOS5.10_i86pc_gcc_64_OPT.OBJ/lib/libplds4.a 
Text relocation remains                         referenced
    against symbol                  offset      in file
big_mul_set_vec64                   0x449      
../../../../../../dist/SunOS5.10_i86pc_gcc_64_OPT.OBJ/lib/libfreebl.a(mpi_amd64_asm.o)
big_mul_add_vec64                   0x46e      
../../../../../../dist/SunOS5.10_i86pc_gcc_64_OPT.OBJ/lib/libfreebl.a(mpi_amd64_asm.o)
ld: fatal: relocations remain against allocatable but non-writable sections
collect2: ld returned 1 exit status

The functions referenced are assembly code for MPI on AMD which we haven't yet
committed to CVS . There is no problem linking that MPI code anywhere but in
fortezza, such as in libsoftokn3.so, or in the many tools under cmd that link
freebl.a .

This error caused me to investigate the build of libswft.so more closely .
I found that there is no DEF file for this PKCS#11 library. On Unix, this causes
all the symbols to be strong and exported  by default .

This is not the right thing to do. We need a DEF file for libfort.so .
Or we could just get rid of the entire lib/fortcrypt .

Comment 1

[Julien Pierre]

I tried using the same DEF file as for softokn, except for the "LIBRARY" line,
which is the library name. I added it in the manifest.mn as the MAPFILE .
I then got the following error :

[jp96085@nss-amd-solaris]/home/jp96085/nss/opt/mozilla/security/nss/lib/fortcrypt/swfort/pkcs11
178 % gmake all
rm -f SunOS5.10_i86pc_gcc_64_OPT.OBJ/libswft.so
gcc -m64 -shared -h libswft.so -Wl,-M,SunOS5.10_i86pc_gcc_64_OPT.OBJ/swft.def -R
'$ORIGIN' -o SunOS5.10_i86pc_gcc_64_OPT.OBJ/libswft.so
SunOS5.10_i86pc_gcc_64_OPT.OBJ/forsock.o
SunOS5.10_i86pc_gcc_64_OPT.OBJ/fortpk11.o
SunOS5.10_i86pc_gcc_64_OPT.OBJ/fmutex.o SunOS5.10_i86pc_gcc_64_OPT.OBJ/stub.o  
../../../../../../dist/SunOS5.10_i86pc_gcc_64_OPT.OBJ/lib/libswfci.a
../../../../../../dist/SunOS5.10_i86pc_gcc_64_OPT.OBJ/lib/libsoftokn.a
../../../../../../dist/SunOS5.10_i86pc_gcc_64_OPT.OBJ/lib/libfreebl.a 
../../../../../../dist/SunOS5.10_i86pc_gcc_64_OPT.OBJ/lib/libsecutil.a
../../../../../../dist/SunOS5.10_i86pc_gcc_64_OPT.OBJ/lib/libplc4.a
../../../../../../dist/SunOS5.10_i86pc_gcc_64_OPT.OBJ/lib/libplds4.a  
ld: fatal: symbol `C_GetFunctionList' is multiply-defined:
        (file SunOS5.10_i86pc_gcc_64_OPT.OBJ/fortpk11.o type=FUNC; file
../../../../../../dist/SunOS5.10_i86pc_gcc_64_OPT.OBJ/lib/libsoftokn.a(pkcs11.o)
type=FUNC);
ld: fatal: File processing errors. No output written to
SunOS5.10_i86pc_gcc_64_OPT.OBJ/libswft.so
collect2: ld returned 1 exit status
gmake: *** [SunOS5.10_i86pc_gcc_64_OPT.OBJ/libswft.so] Error 1

It seems that we are linking two PKCS#11 implementations into one shared library
- one from fortpk11.o, and another from libsoftokn.a .
I assume we want to export the code for fortpk11.o, but how do we specify it
when there are two implementations ? Were we previously relying on the linker
order to choose the proper symbols for us ?
This seems like a big mess.
Could we perhaps choose the specific object files we need from libsoftokn to
link into libswft and avoid the symbol clashes ?

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

I vaguely remember seeing this error string "Text relocation remains" 
a long time ago when I was adding some other assembler code to NSS.  
A google search on the string "Text relocation remains" reveals 
many pages that discuss this problem.  There seems to be universal
agreement that the problem involves a mixture of PIC and non-PIC code.

Comment 3

[Julien Pierre]

I played with the -fPIC option for gcc for a while to no avail. I made the first
linker problem go away by removing one of the assembly functions from the .s
files which was making call instructions . That function fortunately wasn't
actually called so it was an acceptable solution.

I think we still need to fix the story regarding the DEF file for libswft.so, so
I'm leaving this bug open .

Comment 4

[Robert Relyea]

While a .def file is easy to add, we could also just turn off building
libswft.so as well.

bob

Comment 5

[Julien Pierre]

Yes, I would be in favor of just getting rid of libswft to solve this problem .
I will mark this bug as depending on 239960 "remove all fortezza support".
I'm not sure whicih release we are targetting for the removal . Setting 3.11 for
now .

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

Attachment: remove fortezza residue

My recent checking to nss/lib/manifest.mn for bug 239960 has stopped building
the lib/fortcrypt directory entirely.  So I think this bug is now effectively 
resolved/fixed.  Agreed?  

The attached patch here would cleanup some other fortezza residue from
nss/lib/Makefile.

Comment 7

[Julien Pierre]

Comment on attachment 193018 [details] [diff] [review]
remove fortezza residue

r+, though I think this patch probably belonged in the main "remove fortezza"
bug .

Comment 8

[Robert Relyea]

re comment 4 and comment 6...

I think I agree;).

bob

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

what work remains to be done for this bug?
Has the above patch been checked in?
Are there files that need to be "cvs remove"d ?

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

(Should this bug be assigned to me? :)

Comment 11

[Robert Relyea]

The trunk has fortcrypt removed from it's manifest, which is sufficient to close
this bug.

It wouldn't be a bad idea to cvs remove everything in fortcrypt on down
(fortcrypt has two subdirectories, libci and swfort).

bob

Comment 12

[Robert Relyea]

Attachment: Files to be removed.

Here are the files to be cvs removed. (I could attach a patch of the 'code' to
be removed, but it would be bigger than it needs to be).

Comment 13

[Wan-Teh Chang]

Comment on attachment 197776 [details]
Files to be removed.

r=wtc.

Comment 14

[Julien Pierre]

Comment on attachment 197776 [details]
Files to be removed.

Yes, these files should be removed

Comment 15

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 197776 [details]
Files to be removed.

I see this was in lib/fortcrypt.  Two reviews for this list is enough. :)

Comment 16

[Nelson Bolyard (seldom reads bugmail)]

resolved/fixed now?

Comment 17

[Robert Relyea]

resolved fixed

Comment 18

[Wan-Teh Chang]

I found and cvs removed a .cvsignore file in
lib/fortcrypt/swfort/pkcs11.  I verified that
the lib/fortcrypt directory is empty now.