link error - xunlink unsatisfied - HP UX

This is a discussion on link error - xunlink unsatisfied - HP UX ; When I link my program using the command: gcc -o fe -lpthread fe.o mylib.sl I get the error: /usr/ccs/bin/ld: Unsatisfied symbols: xunlink (code) Does anyone know why this is happening? uname -a HP-UX hpux B.11.11 U 9000/800 892008281 unlimited-user license...

+ Reply to Thread
Results 1 to 11 of 11

Thread: link error - xunlink unsatisfied

  1. link error - xunlink unsatisfied

    When I link my program using the command:
    gcc -o fe -lpthread fe.o mylib.sl
    I get the error:
    /usr/ccs/bin/ld: Unsatisfied symbols:
    xunlink (code)

    Does anyone know why this is happening?

    uname -a
    HP-UX hpux B.11.11 U 9000/800 892008281 unlimited-user license



  2. Re: link error - xunlink unsatisfied

    programmer wrote:
    > When I link my program using the command:
    > gcc -o fe -lpthread fe.o mylib.sl
    > I get the error:
    > /usr/ccs/bin/ld: Unsatisfied symbols:
    > xunlink (code)


    > Does anyone know why this is happening?


    > uname -a
    > HP-UX hpux B.11.11 U 9000/800 892008281 unlimited-user license


    I'm not a compiler guy but I think I've seen enough of their responses
    to take a stab at it.

    First, IIRC system libraries should be at the end of the links, so the
    -lpthread should be at the end, not the beginning.

    Second, the message means that something - either in fe, mylib or
    those things on which they depend is tryng to reference a routine
    called xunlink and the linker is not able to resolve that reference
    for them.

    So, for now, first fix-up the link-order. If the problem persists,
    find who is trying to call xunlink and work from there.

    rick jones
    --
    The computing industry isn't as much a game of "Follow The Leader" as
    it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
    - Rick Jones
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  3. Re: link error - xunlink unsatisfied

    In article , Rick Jones wrote:
    > programmer wrote:
    >> When I link my program using the command:
    >> gcc -o fe -lpthread fe.o mylib.sl
    >> I get the error:
    >> /usr/ccs/bin/ld: Unsatisfied symbols:
    >> xunlink (code)

    >
    >> Does anyone know why this is happening?

    >
    >> uname -a
    >> HP-UX hpux B.11.11 U 9000/800 892008281 unlimited-user license

    >
    > I'm not a compiler guy but I think I've seen enough of their responses
    > to take a stab at it.
    >
    > First, IIRC system libraries should be at the end of the links, so the
    > -lpthread should be at the end, not the beginning.


    I'm no expert here either, but at least for compiling Perl, you need pthread at
    the front of the list...

    > Second, the message means that something - either in fe, mylib or
    > those things on which they depend is tryng to reference a routine
    > called xunlink and the linker is not able to resolve that reference
    > for them.
    >
    > So, for now, first fix-up the link-order. If the problem persists,
    > find who is trying to call xunlink and work from there.


    Kevin
    --
    Unix Guy Consulting, LLC
    Unix and Linux Automation, Shell, Perl and CGI scripting
    http://www.unix-guy.com

  4. Re: link error - xunlink unsatisfied

    Kevin Collins writes:

    > In article , Rick Jones wrote:
    >> First, IIRC system libraries should be at the end of the links, so the
    >> -lpthread should be at the end, not the beginning.

    >
    > I'm no expert here either, but at least for compiling Perl, you need pthread at
    > the front of the list...


    Well, I am an expert (at least a self-proclaimed one , and
    you don't need -lpthread at the front, when *linking* Perl (or
    anything else). It should be at the end together with all the other
    system libraries [1].

    [1] Actually, with shared libraries it doesn't much matter whether
    the libraries are at the beginning or the end of the link line [2].
    But it does matter a *lot* if archive libraries are used.
    More info here:
    http://webpages.charter.net/ppluzhnikov/linker.html

    [2] So long as "system symbols" aren't redefined [3].
    [3] Which is a terrible idea (TM).

    Cheers,
    --
    In order to understand recursion you must first understand recursion.
    Remove /-nsp/ for email.

  5. Re: link error - xunlink unsatisfied

    In article , Paul Pluzhnikov
    wrote:
    > Kevin Collins writes:
    >
    >> In article , Rick Jones wrote:
    >>> First, IIRC system libraries should be at the end of the links, so the
    >>> -lpthread should be at the end, not the beginning.

    >>
    >> I'm no expert here either, but at least for compiling Perl, you need pthread at
    >> the front of the list...

    >
    > Well, I am an expert (at least a self-proclaimed one , and
    > you don't need -lpthread at the front, when *linking* Perl (or
    > anything else). It should be at the end together with all the other
    > system libraries [1].


    Have you ever tried to compile the DBD::Oracle Perl module on HP-UX? If not, go
    ahead and try - I'll wait...

    If you do not specify -lcl and -lpthread as the 1st libraries to link, you WILL
    NOT get a usable shared library. It will fail to load, and is a well-known
    issue with Perl and HP-UX.

    > [1] Actually, with shared libraries it doesn't much matter whether
    > the libraries are at the beginning or the end of the link line [2].
    > But it does matter a *lot* if archive libraries are used.
    > More info here:
    > http://webpages.charter.net/ppluzhnikov/linker.html
    >
    > [2] So long as "system symbols" aren't redefined [3].
    > [3] Which is a terrible idea (TM).


    Kevin
    --
    Unix Guy Consulting, LLC
    Unix and Linux Automation, Shell, Perl and CGI scripting
    http://www.unix-guy.com

  6. Re: link error - xunlink unsatisfied

    Kevin Collins writes:

    > Have you ever tried to compile the DBD::Oracle Perl module on HP-UX?


    No, I have not.

    However, I continue to claim that your "-lpthread first" statement
    is totally bogus.

    > If not, go ahead and try - I'll wait...


    I could do that, but that will prove nothing -- you'll just claim
    that your version of Perl or DBD::Oracle was different.

    So if you want me to prove you wrong, please state *exact* version
    of Perl and DBD::Oracle that allegedly requires "-lpthread first",
    including how that Perl was configured.

    > If you do not specify -lcl and -lpthread as the 1st libraries to link, you WILL
    > NOT get a usable shared library.


    The instructions here:
    http://search.cpan.org/~pythian/DBD-...EADME.hpux.txt
    explain that you must rebuild Perl itself with '-lpthread' (and do
    not state, but I assure you '-lpthread' goes at the end).

    Once you do that, it wouldn't even matter whether DBD::Oracle shared
    library links with -lpthread or not.

    And if you don't do that, it doesn't matter where you put '-lpthread'
    when linking DBD::Oracle, as the result will be completely undefined
    either way.

    > It will fail to load, and is a well-known issue with Perl and HP-UX.


    I think you are just repeating an "urban legend", without
    understanding the problem.

    There is a well-known issue with Perl and DBD::Oracle, but it has
    nothing to do with where on the link line '-lpthread' goes.

    Cheers,
    --
    In order to understand recursion you must first understand recursion.
    Remove /-nsp/ for email.

  7. Re: link error - xunlink unsatisfied

    In article , Paul Pluzhnikov
    wrote:
    > Kevin Collins writes:
    >
    >> Have you ever tried to compile the DBD::Oracle Perl module on HP-UX?

    >
    > No, I have not.
    >
    > However, I continue to claim that your "-lpthread first" statement
    > is totally bogus.
    >
    >> If not, go ahead and try - I'll wait...

    >
    > I could do that, but that will prove nothing -- you'll just claim
    > that your version of Perl or DBD::Oracle was different.
    >
    > So if you want me to prove you wrong, please state *exact* version
    > of Perl and DBD::Oracle that allegedly requires "-lpthread first",
    > including how that Perl was configured.
    >
    >> If you do not specify -lcl and -lpthread as the 1st libraries to link, you WILL
    >> NOT get a usable shared library.

    >
    > The instructions here:
    > http://search.cpan.org/~pythian/DBD-...EADME.hpux.txt
    > explain that you must rebuild Perl itself with '-lpthread' (and do
    > not state, but I assure you '-lpthread' goes at the end).
    >
    > Once you do that, it wouldn't even matter whether DBD::Oracle shared
    > library links with -lpthread or not.
    >
    > And if you don't do that, it doesn't matter where you put '-lpthread'
    > when linking DBD::Oracle, as the result will be completely undefined
    > either way.


    And if you read ALL of the README you point to you will find this text:

    "BTW: If you add -lcl and -lpthread to the end of the list it will not work. I
    wasted a day and a half trying to figure out why I had lost the recipe, before
    I realized that this was the problem."

    >> It will fail to load, and is a well-known issue with Perl and HP-UX.

    >
    > I think you are just repeating an "urban legend", without
    > understanding the problem.
    >
    > There is a well-known issue with Perl and DBD::Oracle, but it has
    > nothing to do with where on the link line '-lpthread' goes.


    Feel completely free to educate me - I have no issue with being enlightened.
    However, you seem bent on proving me wrong, do it with facts please.

    Thanks,

    Kevin

    --
    Unix Guy Consulting, LLC
    Unix and Linux Automation, Shell, Perl and CGI scripting
    http://www.unix-guy.com

  8. Re: link error - xunlink unsatisfied

    Kevin Collins writes:

    > And if you read ALL of the README you point to you will find this text:
    >
    > "BTW: If you add -lcl and -lpthread to the end of the list it will not work. I
    > wasted a day and a half trying to figure out why I had lost the recipe, before
    > I realized that this was the problem."


    There is in fact such a statement in the README.
    What's not clear is exactly *which* list it is talking about.

    > Feel completely free to educate me - I have no issue with being enlightened.
    > However, you seem bent on proving me wrong, do it with facts please.


    So here are the facts:

    If one is to build perl-5.8.8 after
    sh ./Configure -A prepend:libswanted='cl pthread ' -des
    then the *actual* link line for perl is:

    cc -o perl +DD64 -L/usr/local/lib -L/lib/pa20_64 -Wl,-E \
    -Wl,-B,deferred perlmain.o lib/auto/DynaLoader/DynaLoader.a \
    libperl.a `cat ext.libs` -lcl -lpthread -lnsl -lnm -ldl -ldld -lm -lsec -lc

    From this, it is clear that the list in the "BTW" note is the list of
    system libraries, *not* the list of all arguments (which is what
    started our exchange).

    Further, the "BTW" note says that if '-lcl -lpthread' is moved to
    the end, then "make test" will fail.

    I did move it to the end "by hand", and reran "make test", just so
    I can see *why* it would fail. However it didn't fail, so the "BTW"
    note itself is either wrong, or applies only to a different release
    of the OS or the compiler/linker.

    Cheers,
    --
    In order to understand recursion you must first understand recursion.
    Remove /-nsp/ for email.

  9. Re: link error - xunlink unsatisfied

    In article , Paul Pluzhnikov
    wrote:
    > Kevin Collins writes:
    >
    >> And if you read ALL of the README you point to you will find this text:
    >>
    >> "BTW: If you add -lcl and -lpthread to the end of the list it will not work. I
    >> wasted a day and a half trying to figure out why I had lost the recipe, before
    >> I realized that this was the problem."

    >
    > There is in fact such a statement in the README.
    > What's not clear is exactly *which* list it is talking about.
    >
    >> Feel completely free to educate me - I have no issue with being enlightened.
    >> However, you seem bent on proving me wrong, do it with facts please.

    >
    > So here are the facts:
    >
    > If one is to build perl-5.8.8 after
    > sh ./Configure -A prepend:libswanted='cl pthread ' -des
    > then the *actual* link line for perl is:
    >
    > cc -o perl +DD64 -L/usr/local/lib -L/lib/pa20_64 -Wl,-E \
    > -Wl,-B,deferred perlmain.o lib/auto/DynaLoader/DynaLoader.a \
    > libperl.a `cat ext.libs` -lcl -lpthread -lnsl -lnm -ldl -ldld -lm -lsec -lc
    >
    > From this, it is clear that the list in the "BTW" note is the list of
    > system libraries, *not* the list of all arguments (which is what
    > started our exchange).


    Ok, so that makes sense so far...

    > Further, the "BTW" note says that if '-lcl -lpthread' is moved to
    > the end, then "make test" will fail.
    >
    > I did move it to the end "by hand", and reran "make test", just so
    > I can see *why* it would fail. However it didn't fail, so the "BTW"
    > note itself is either wrong, or applies only to a different release
    > of the OS or the compiler/linker.


    That is because you were compiling 'perl' and not DBD-Oracle. The note is about
    the perl executable, but the 'make test' is referring to DBD-Oracle.

    If you now perform a 'make install' of perl as you compiled it, then use that
    perl to configure and install DBI and then get DBD-Oracle and run configure,
    make, make test, the make test will fail.

    Trust me, it will happen - I've seen it from at least 11.00 thru 11.23 on
    PA-RISC and Itanium...

    Kevin
    --
    Unix Guy Consulting, LLC
    Unix and Linux Automation, Shell, Perl and CGI scripting
    http://www.unix-guy.com

  10. Re: link error - xunlink unsatisfied

    Kevin Collins writes:

    > That is because you were compiling 'perl' and not DBD-Oracle. The note is about
    > the perl executable, but the 'make test' is referring to DBD-Oracle.
    >
    > If you now perform a 'make install' of perl as you compiled it, then use that
    > perl to configure and install DBI and then get DBD-Oracle and run configure,
    > make, make test, the make test will fail.


    I did, and it didn't fail (using Oracle 8.1.7; the only version I have).

    In fact, it would make absolutely no sense for it to fail:
    if 'perl' itself has been linked with libpthread.sl, then it
    *doesn't* matter whether Oracle.sl links with libpthread at all --
    libpthread is loaded when perl itself is, and when subsequent load
    of Oracle.sl comes, the runtime loader merely increments libpthread
    reference count, but doesn't load another copy of it.

    In fact, the final link line for Oracle.sl has neither -lcl nor
    -lpthread anywhere on it.

    > Trust me, it will happen


    The problem is that I don't trust you (mostly because you are
    telling me something I know to be false).

    But I think I've run out of options to convince you, and you probably
    have run out of options to convince me; so will just have to continue
    to believe that the other one is wrong.

    Cheers
    --
    In order to understand recursion you must first understand recursion.
    Remove /-nsp/ for email.

  11. Re: link error - xunlink unsatisfied

    Paul Pluzhniko wrote:
    : It should be at the end together with all the other system libraries [1].

    But better be before libc.

    : [1] Actually, with shared libraries it doesn't much matter whether
    : the libraries are at the beginning or the end of the link line [2].

    That's not strictly true. With C++ shared libs, there is a static init
    order that when changed could break things. And several ISVs ran into
    one after I made a change.
    (That's if you change the relative shlib order.)

    : But it does matter a *lot* if archive libraries are used.

    Right.

    >From: Kevin Collins
    >make test, the make test will fail.


    Because of the libpthread libc ordering?

    >From: Paul Pluzhnikov
    >In fact, it would make absolutely no sense for it to fail:
    >if 'perl' itself has been linked with libpthread.sl, then it
    >*doesn't* matter whether Oracle.sl links with libpthread at all --


    That may be true for PA32 but PA64 has a different search ordering.
    depth vs breadth.
    And when it came out, there were no end of issues and unexpected problems.

    >libpthread is loaded when perl itself is, and when subsequent load
    >of Oracle.sl comes, the runtime loader merely increments libpthread
    >reference count, but doesn't load another copy of it.


    Yes but the symbol order binding could be changed.

    >The problem is that I don't trust you (mostly because you are
    >telling me something I know to be false).


    There are gotchas with libpthread ordering and dependent shlibs.

+ Reply to Thread