compiler export file differences - Aix

This is a discussion on compiler export file differences - Aix ; Hi, I'm getting additional symbols in my export files that are used to create shared libraries and don't know why. The differences are apparent in the migration from AIX 5.1, with Visual Age C++ 6 and AIX 5.3, with XL ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: compiler export file differences

  1. compiler export file differences

    Hi,

    I'm getting additional symbols in my export files that are used to
    create shared libraries and don't know why.

    The differences are apparent in the migration from

    AIX 5.1, with Visual Age C++ 6

    and

    AIX 5.3, with XL C/C++ 8.0

    I have provided the output from the dump command below to show this:

    ** Ok, old server first (AIX 5.1, Visual Age C++ 6) - this binary
    works:

    >dump -H setP


    setP:

    ***Loader Section***
    Loader Header Information
    VERSION# #SYMtableENT #RELOCent LENidSTR
    0x00000001 0x000000a8 0x00000365 0x00000144

    #IMPfilID OFFidSTR LENstrTBL OFFstrTBL
    0x0000000b 0x0000389c 0x00000fea 0x000039e0


    ***Import File Strings***
    INDEX PATH BASE MEMBER
    0
    /usr/u/e/dv/beta30.42/lib:/usr/tuxedo/cr/lib:/usr/rw/cr/lib:/usr/lpp/
    xlopt:/usr/vacpp/lib:/usr/lib:/lib


    1 libc.a shr.o
    2 libutxexec.a libutxexec.o
    3 libC.a ansi_32.o
    4 libC.a shr2.o
    5 libC.a shr.o
    6 libC.a shr3.o
    7 libRWDbCore8d.a dbt8d.o
    8 libdb.a libdb.o
    9 libUshare.a
    10 libRWTools8d.a tls8d.o


    ** Now, the new server (AIX 5.3, XL C/C++ 8.0). As you can see it has
    extra symbols that are not
    being used and have nothing to do with the binary:

    >dump -H setP


    setP:

    ***Loader Section***
    Loader Header Information
    VERSION# #SYMtableENT #RELOCent LENidSTR
    0x00000001 0x0000011e 0x00000319 0x000001ec

    #IMPfilID OFFidSTR LENstrTBL OFFstrTBL
    0x00000013 0x0000401c 0x00002c9e 0x00004208


    ***Import File Strings***
    INDEX PATH BASE MEMBER
    0
    /usr/u/e/dv/home/mk/lib:/usr/tuxedo/cr/lib:/usr/rw/cr/lib:/usr/vac/
    lib:/usr/vacpp/lib:/usr/lib:/lib


    1 libc.a shr.o
    2 libPBC.a
    3 libC.a shr2.o
    4 libC.a shr3.o
    5 libUshare.a
    6 libTrnAct.a
    7 libC.a ansi_32.o
    8 libC.a shr.o
    9 libArcMgr.a
    10 libutxexec.a libutxexec.o
    11 libAcBal.a
    12 libdb.a libdb.o
    13 libRWDbCore8d.a dbt8d.o
    14 libAdv.a
    15 libAudit.a
    16 libTrnTps.a
    17 libAutoCalMsgBMgr.a
    18 libRWTools8d.a tls8d.o


    Note: This post is related to my yet unanswered in this forum last
    week:
    http://groups.google.com/group/comp....8c2a56fb2b81d7

    Regards,

    Michael


  2. Re: compiler export file differences

    MK wrote:
    > I'm getting additional symbols in my export files that are used to
    > create shared libraries and don't know why.


    Wow, where to start.

    > ** Now, the new server (AIX 5.3, XL C/C++ 8.0). As you can see it has
    > extra symbols that are not
    > being used and have nothing to do with the binary:


    We see nothing of the sort. What you show us is that the newer build
    has additional _dependencies_. Yes, this implies other referenced
    symbols, but they're not shown here.

    >
    > Note: This post is related to my yet unanswered in this forum last
    > week:


    So I glanced at your other post, and I would strongly suggest you stop
    building your own export lists. The method you're using is not correct.

    Either let 'xlC -qmkshrobj -qtwolink' create its own export list for
    you, which is going to be every defined symbol in your object code
    (if you're specifying things correctly on the command line), or use
    /usr/vac/bin/CreateExportList yourself. Stop trying to be smarter
    than the compiler.

    And MakeC++SharedLib has been deprecated, AFAIK.

    ------------------------------------------------------------------------
    http://www.photo.net/photos/garyrhook
    /Vocatus atque non vocatus deus aderit/

  3. Re: compiler export file differences

    On May 16, 7:01 am, "Gary R. Hook" wrote:
    > MK wrote:
    > > I'm getting additional symbols in my export files that are used to
    > > create shared libraries and don't know why.

    >
    > Wow, where to start.
    >
    > > ** Now, the new server (AIX 5.3, XL C/C++ 8.0). As you can see it has
    > > extra symbols that are not
    > > being used and have nothing to do with the binary:

    >
    > We see nothing of the sort. What you show us is that the newer build
    > has additional _dependencies_. Yes, this implies other referenced
    > symbols, but they're not shown here.
    >
    >
    >
    > > Note: This post is related to my yet unanswered in this forum last
    > > week:

    >
    > So I glanced at your other post, and I would strongly suggest you stop
    > building your own export lists. The method you're using is not correct.
    >
    > Either let 'xlC -qmkshrobj -qtwolink' create its own export list for
    > you, which is going to be every defined symbol in your object code
    > (if you're specifying things correctly on the command line), or use
    > /usr/vac/bin/CreateExportList yourself. Stop trying to be smarter
    > than the compiler.
    >
    > And MakeC++SharedLib has been deprecated, AFAIK.
    >
    > ------------------------------------------------------------------------http://www.photo.net/photos/garyrhook
    > /Vocatus atque non vocatus deus aderit/


    Thanks for taking the time to look at this Gary.

    My apologies, not symbols but dependancies. The make files are
    existing files that were created years ago, that's why I questioned
    the creation of the export files and shared libs.

    So, why the extra symbols on this new build?

    Yes, the recommendation is to use -qmkshrobj over MakeC++SharedLib.

    Now, I used

    xlC -qmkshrobj -qexpfile=$(EXPORT_FILE) $(OBJECTS)

    to create the export files and

    xlC -qmkshrobj $(OBJECTS) -o $(ARCHIVE) -bE:$(EXPORTS)

    to create the shared libraries given the list of export files, but
    still the same issue. I haven't used the -qtwolink option yet.

    Regards,

    Michael


+ Reply to Thread