problem with shared libraris - SGI

This is a discussion on problem with shared libraris - SGI ; Hello, building shared libraries for openssl-0.9.7c does not work. The makefile builds the shared libraris starting from the static libraries and this looks like not working: gcc -shared -o libcrypto.so.0.9.7 -Wl,-soname,libcrypto.so.0.9.7 -all libcrypto.a -L. -lc ld32: WARNING 84: libcrypto.a is ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: problem with shared libraris

  1. problem with shared libraris

    Hello,
    building shared libraries for openssl-0.9.7c does not work.
    The makefile builds the shared libraris starting from the static libraries
    and this looks like not working:
    gcc -shared -o libcrypto.so.0.9.7 -Wl,-soname,libcrypto.so.0.9.7
    -all libcrypto.a -L. -lc
    ld32: WARNING 84: libcrypto.a is not used for resolving any symbol.
    ld32: WARNING 84: /usr/lib32/libc.so is not used for resolving any symbol.
    + gcc -shared -o libssl.so.0.9.7 -Wl,-soname,libssl.so.0.9.7
    -all libssl.a -lcrypto -L. -lc
    ld32: WARNING 84: libssl.a is not used for resolving any symbol.
    ld32: WARNING 84: ./libcrypto.a is not used for resolving any symbol.
    ld32: WARNING 84: /usr/lib32/libc.so is not used for resolving any symbol.


    looks like no "gcc -fPIC" option is ever used with openssl distribution for
    IRIX openssl build.
    What I have to do to build with shared library support ?
    For some reason I need to use the latest openssl and compile it myself.
    anyone has a hint with shared libraries ?
    thanks

    Rick


  2. Re: problem with shared libraris

    In article ,
    Riccardo Veraldi wrote:
    >Hello,
    >building shared libraries for openssl-0.9.7c does not work.
    >The makefile builds the shared libraris starting from the static libraries
    >and this looks like not working:
    >gcc -shared -o libcrypto.so.0.9.7 -Wl,-soname,libcrypto.so.0.9.7
    >-all libcrypto.a -L. -lc
    >ld32: WARNING 84: libcrypto.a is not used for resolving any symbol.
    >ld32: WARNING 84: /usr/lib32/libc.so is not used for resolving any symbol.


    -all is understood by IRIX cc, but not AFAICT by gcc (well,
    not documented as of gcc 3.2.2-5).

    >+ gcc -shared -o libssl.so.0.9.7 -Wl,-soname,libssl.so.0.9.7
    >-all libssl.a -lcrypto -L. -lc
    >ld32: WARNING 84: libssl.a is not used for resolving any symbol.
    >ld32: WARNING 84: ./libcrypto.a is not used for resolving any symbol.
    >ld32: WARNING 84: /usr/lib32/libc.so is not used for resolving any symbol.


    Same problem here.

    >looks like no "gcc -fPIC" option is ever used with openssl distribution for
    >IRIX openssl build.


    Such an option would be understood by gcc, but not by IRIX ld
    (IRIX cc and ld default to PIC output).

    >What I have to do to build with shared library support ?
    >For some reason I need to use the latest openssl and compile it myself.
    >anyone has a hint with shared libraries ?
    >thanks


    You don't show any nm or other output on the shared libraries
    so it's not easy to be quite sure that they are indeed empty.

    Regards,
    David B. Anderson davea at sgi dot com http://reality.sgiweb.org/davea

  3. Re: problem with shared libraris


    libssl.so looks like quite empty:

    Symbols from libssl.so.0.9.7:

    [Index] Value Size Type Bind Other Shndx Name

    [1] | 0| 4967|SECT |LOCL |DEFAULT |MIPS_DATA|.debug_line
    [2] | 0| 1336|SECT |LOCL |DEFAULT |MIPS_DATA|.debug_frame
    [3] | 0| 1112|SECT |LOCL |DEFAULT |MIPS_DATA|.debug_abbrev
    [4] | 0| 21982|SECT |LOCL |DEFAULT |MIPS_DATA|.debug_info
    [5] | 0| 96|SECT |LOCL |DEFAULT |MIPS_DATA|.debug_aranges
    [6] | 0| 404|SECT |LOCL |DEFAULT |MIPS_DATA|.debug_pubnames
    [7] | 0| 440|SECT |LOCL |DEFAULT |MIPS_DATA|.debug_ranges
    [8] | 0| 146|SECT |LOCL |DEFAULT |MIPS_DATA|.debug_str
    [9] |1610353448| 7884|SECT |LOCL |DEFAULT |MIPS_TEXT|.text
    [10] |1610428416| 1362|SECT |LOCL |DEFAULT |MIPS_DATA|.rodata
    [11] |1610429780| 8|SECT |LOCL |DEFAULT |MIPS_DATA|.dtors
    [12] |1610429788| 512|SECT |LOCL |DEFAULT |MIPS_DATA|.eh_frame
    [13] |1610430300| 4|SECT |LOCL |DEFAULT |MIPS_DATA|.data.rel.ro
    [14] |1610430304| 8|SECT |LOCL |DEFAULT |MIPS_DATA|.ctors
    [15] |1610430312| 4|SECT |LOCL |DEFAULT |MIPS_DATA|.jcr
    [16] |1610430432| 40|SECT |LOCL |DEFAULT |MIPS_DATA|.bss
    [17] | 0| 0|SECT |GLOB |PROTECTED|MIPS_TEXT|__dso_displacement
    [18] |1610350592| 0|SECT |GLOB |PROTECTED|MIPS_TEXT|__elf_header
    [19] |1610350644| 0|SECT |GLOB |PROTECTED|MIPS_TEXT|__program_header_
    table
    [20] |1610353448| 128|FUNC |GLOB |HIDDEN |MIPS_TEXT|__do_global_dtors
    [21] |1610354632| 104|FUNC |GLOB |DEFAULT |MIPS_TEXT|__register_frame
    [22] |1610354888| 88|FUNC |GLOB |DEFAULT |MIPS_TEXT|__register_frame_
    table

    etc... it's only MIPS_TEXT stuff.


    I will try to remove the -all option.

    Do you suggest me to install GNU binutils instead of using IRIX ld ?
    In general could I ahve improvements using ld GNU binutils?

    thanks

    Rick

    In article , David Anderson wrote:
    > In article ,
    > Riccardo Veraldi wrote:
    >>Hello,
    >>building shared libraries for openssl-0.9.7c does not work.
    >>The makefile builds the shared libraris starting from the static libraries
    >>and this looks like not working:
    >>gcc -shared -o libcrypto.so.0.9.7 -Wl,-soname,libcrypto.so.0.9.7
    >>-all libcrypto.a -L. -lc
    >>ld32: WARNING 84: libcrypto.a is not used for resolving any symbol.
    >>ld32: WARNING 84: /usr/lib32/libc.so is not used for resolving any symbol.

    >
    > -all is understood by IRIX cc, but not AFAICT by gcc (well,
    > not documented as of gcc 3.2.2-5).
    >
    >>+ gcc -shared -o libssl.so.0.9.7 -Wl,-soname,libssl.so.0.9.7
    >>-all libssl.a -lcrypto -L. -lc
    >>ld32: WARNING 84: libssl.a is not used for resolving any symbol.
    >>ld32: WARNING 84: ./libcrypto.a is not used for resolving any symbol.
    >>ld32: WARNING 84: /usr/lib32/libc.so is not used for resolving any symbol.

    >
    > Same problem here.
    >
    >>looks like no "gcc -fPIC" option is ever used with openssl distribution for
    >>IRIX openssl build.

    >
    > Such an option would be understood by gcc, but not by IRIX ld
    > (IRIX cc and ld default to PIC output).
    >
    >>What I have to do to build with shared library support ?
    >>For some reason I need to use the latest openssl and compile it myself.
    >>anyone has a hint with shared libraries ?
    >>thanks

    >
    > You don't show any nm or other output on the shared libraries
    > so it's not easy to be quite sure that they are indeed empty.
    >
    > Regards,
    > David B. Anderson davea at sgi dot com http://reality.sgiweb.org/davea


  4. Re: problem with shared libraris

    Rick wrote:
    >
    > Do you suggest me to install GNU binutils instead of using IRIX ld ?
    > In general could I ahve improvements using ld GNU binutils?
    >


    GNU and improvement in the same sentence? ahahahahahahahahahah

    ok, sorry back to our normal tuxed up existence.



  5. Re: problem with shared libraris


    I can;t understand why building shared libs from static ones does not work.
    I Removed the -all option and still it does not work.

    Rick

    In article , IRIX Central wrote:
    > Rick wrote:
    >>
    >> Do you suggest me to install GNU binutils instead of using IRIX ld ?
    >> In general could I ahve improvements using ld GNU binutils?
    >>

    >
    > GNU and improvement in the same sentence? ahahahahahahahahahah
    >
    > ok, sorry back to our normal tuxed up existence.
    >
    >


  6. Re: problem with shared libraris

    Riccardo Veraldi wrote:
    >
    > I can;t understand why building shared libs from static ones does not work.
    > I Removed the -all option and still it does not work.
    >


    we will see shortly. i am going to build the garbage compiler(tm) shortly
    for a client using MIPSpro 7.4.1. I will entertain attempting to recreate
    this issue.

    did you read the freeware gcc release notes and/or contact the package
    maintainers about this?

    i do not hear a chorus of "me too" responses so perhaps it is localized.

    cheers

  7. Re: problem with shared libraris


    Well I could build succesfully shared libs for BerkeleyDB.4.1
    for example but it uses another gcc syntax with the -fPIC option.

    I also built gcc-3.3.2 and compiled openssl with gcc-3.3.2 and I still hsve
    the same problem I hsve with fw_gcc (3.3)

    I do not have mips compiler unfortunately, or I guess I would not
    have this problem.

    Maybe that openssl/Configure is guessing wrong options for GCC/mips-irix6.5
    so for this reason I Am unable to build the shared libs.

    THey are complitely empty with no symbols inside if I use nm to see inside them.

    thank you

    Rick





    In article , IRIX Central wrote:
    > Riccardo Veraldi wrote:
    >>
    >> I can;t understand why building shared libs from static ones does not work.
    >> I Removed the -all option and still it does not work.
    >>

    >
    > we will see shortly. i am going to build the garbage compiler(tm) shortly
    > for a client using MIPSpro 7.4.1. I will entertain attempting to recreate
    > this issue.
    >
    > did you read the freeware gcc release notes and/or contact the package
    > maintainers about this?
    >
    > i do not hear a chorus of "me too" responses so perhaps it is localized.
    >
    > cheers


  8. Re: problem with shared libraris

    In article ,
    Riccardo Veraldi wrote:
    >
    >Well I could build succesfully shared libs for BerkeleyDB.4.1
    >for example but it uses another gcc syntax with the -fPIC option.


    You must use IRIX ld. gcc on IRIX can only work if you use
    IRIX ld, GNU ld won't work on IRIX.

    >I also built gcc-3.3.2 and compiled openssl with gcc-3.3.2 and I still hsve
    >the same problem I hsve with fw_gcc (3.3)



    >I do not have mips compiler unfortunately, or I guess I would not
    >have this problem.


    >Maybe that openssl/Configure is guessing wrong options for GCC/mips-irix6.5
    >so for this reason I Am unable to build the shared libs.


    What -all does (with IRIX cc/ld) is to say
    include the entire archive into output shared library (DSO).

    An ugly way to do that with gcc is to list the objects,
    as in
    gcc -shared *.o -o t.so

    If your objects are all C, then it's simple to use ld:
    Example:
    ld -shared -mips3 -n32 -o t.so -all myarchive.a -notall -lc

    The -notall is not really needed.

    >THey are complitely empty with no symbols inside if I use nm to see inside them.
    >
    >thank you
    >
    >In article , IRIX Central wrote:
    >> Riccardo Veraldi wrote:
    >>>
    >>> I can;t understand why building shared libs from static ones does not work.
    >>> I Removed the -all option and still it does not work.


    Yes, well, that's not going to help. The -all was ineffective because
    it is not recognized as an ld option by gcc, and nothing useful
    happens.
    Use gcc options to pass the options -all to ld:
    gcc -Wl,-all myarchive.a
    should work (if gcc maintains the correct order of options).


    >> we will see shortly. i am going to build the garbage compiler(tm) shortly
    >> for a client using MIPSpro 7.4.1. I will entertain attempting to recreate
    >> this issue.
    >>
    >> did you read the freeware gcc release notes and/or contact the package
    >> maintainers about this?
    >>
    >> i do not hear a chorus of "me too" responses so perhaps it is localized.
    >>
    >> cheers


    Hope this helps.
    David Anderson

  9. Re: problem with shared libraris


    thank you.
    this worked:

    ld -shared -mips4 -n32 -o libssl.so.0.9.7 -all libssl.a -lc

    the gcc command which was using into the Makefile:

    gcc -shared -o libssl.so.0.9.7 -Wl,-soname,libssl.so.0.9.7 \
    -all libssl.a -lc

    instead produced empty so files

    thank you very much


    Rick


    In article , David Anderson wrote:
    > In article ,
    > Riccardo Veraldi wrote:
    >>
    >>Well I could build succesfully shared libs for BerkeleyDB.4.1
    >>for example but it uses another gcc syntax with the -fPIC option.

    >
    > You must use IRIX ld. gcc on IRIX can only work if you use
    > IRIX ld, GNU ld won't work on IRIX.
    >
    >>I also built gcc-3.3.2 and compiled openssl with gcc-3.3.2 and I still hsve
    >>the same problem I hsve with fw_gcc (3.3)

    >
    >
    >>I do not have mips compiler unfortunately, or I guess I would not
    >>have this problem.

    >
    >>Maybe that openssl/Configure is guessing wrong options for GCC/mips-irix6.5
    >>so for this reason I Am unable to build the shared libs.

    >
    > What -all does (with IRIX cc/ld) is to say
    > include the entire archive into output shared library (DSO).
    >
    > An ugly way to do that with gcc is to list the objects,
    > as in
    > gcc -shared *.o -o t.so
    >
    > If your objects are all C, then it's simple to use ld:
    > Example:
    > ld -shared -mips3 -n32 -o t.so -all myarchive.a -notall -lc
    >
    > The -notall is not really needed.
    >
    >>THey are complitely empty with no symbols inside if I use nm to see inside them.
    >>
    >>thank you
    >>
    >>In article , IRIX Central wrote:
    >>> Riccardo Veraldi wrote:
    >>>>
    >>>> I can;t understand why building shared libs from static ones does not work.
    >>>> I Removed the -all option and still it does not work.

    >
    > Yes, well, that's not going to help. The -all was ineffective because
    > it is not recognized as an ld option by gcc, and nothing useful
    > happens.
    > Use gcc options to pass the options -all to ld:
    > gcc -Wl,-all myarchive.a
    > should work (if gcc maintains the correct order of options).
    >
    >
    >>> we will see shortly. i am going to build the garbage compiler(tm) shortly
    >>> for a client using MIPSpro 7.4.1. I will entertain attempting to recreate
    >>> this issue.
    >>>
    >>> did you read the freeware gcc release notes and/or contact the package
    >>> maintainers about this?
    >>>
    >>> i do not hear a chorus of "me too" responses so perhaps it is localized.
    >>>
    >>> cheers

    >
    > Hope this helps.
    > David Anderson


+ Reply to Thread