libswft.so linking problems ; needs DEF file

VERIFIED FIXED in 3.11

Status

NSS
Libraries
P1
normal
VERIFIED FIXED
13 years ago
12 years ago

People

(Reporter: Julien Pierre, Assigned: Robert Relyea)

Tracking

(Depends on: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

13 years ago
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 .
(Reporter)

Comment 1

13 years ago
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 ?
Priority: -- → P1
Target Milestone: --- → 3.9.5
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.

(Reporter)

Comment 3

13 years ago
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 .
QA Contact: bishakhabanerjee → jason.m.reid
(Assignee)

Comment 4

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

bob
(Reporter)

Comment 5

13 years ago
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 .
Depends on: 239960
Target Milestone: 3.9.5 → 3.11
Created attachment 193018 [details] [diff] [review]
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.
Attachment #193018 - Flags: review?(julien.pierre.bugs)
(Reporter)

Comment 7

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

r+, though I think this patch probably belonged in the main "remove fortezza"
bug .
Attachment #193018 - Flags: review?(julien.pierre.bugs) → review+

Updated

13 years ago
Attachment #193018 - Flags: review+
(Assignee)

Comment 8

13 years ago
re comment 4 and comment 6...

I think I agree;).

bob
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 ?
(Should this bug be assigned to me? :)
(Assignee)

Comment 11

13 years ago
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

(Assignee)

Comment 12

13 years ago
Created attachment 197776 [details]
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).
Attachment #197776 - Flags: superreview?(wtchang)
Attachment #197776 - Flags: review?(nelson)

Comment 13

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

r=wtc.
Attachment #197776 - Flags: superreview?(wtchang) → superreview+
(Reporter)

Comment 14

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

Yes, these files should be removed
Attachment #197776 - Flags: review+
Comment on attachment 197776 [details]
Files to be removed.

I see this was in lib/fortcrypt.  Two reviews for this list is enough. :)
Attachment #197776 - Flags: review?(nelson)
resolved/fixed now?
(Assignee)

Comment 17

13 years ago
resolved fixed
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED

Comment 18

13 years ago
I found and cvs removed a .cvsignore file in
lib/fortcrypt/swfort/pkcs11.  I verified that
the lib/fortcrypt directory is empty now.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.