Library link failure for -xarch=amd64 w/ Solaris 10 & Studio 11 - Solaris

This is a discussion on Library link failure for -xarch=amd64 w/ Solaris 10 & Studio 11 - Solaris ; I'm trying to figure out what commandline options I need to use to link properly for the AMD64 architecture. If I link a bunch of object files it works fine. However, if I try to link the same objects from ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Library link failure for -xarch=amd64 w/ Solaris 10 & Studio 11

  1. Library link failure for -xarch=amd64 w/ Solaris 10 & Studio 11

    I'm trying to figure out what commandline options I need to use to link
    properly for the AMD64 architecture.

    If I link a bunch of object files it works fine. However, if I try to
    link the same objects from a library it fails. The problem seems to be
    related to the tagging of architecture dependencies in the library. It
    doesn't happen unless I use -xarch=amd64 or xarch=amd64a.

    I've googled w/o success and am going blind RTFM for cc & ld.

    Does anyone have any hints or suggestions?

    Thanks,
    rhb

    Here's a small example and the console output. I've tried many other
    option permutations w/o any change in behavior.

    ::::::::::::::
    Makefile
    ::::::::::::::

    CFLAGS = -fast -xdepend=yes -xvector=simd -xarch=amd64

    foo.o: foo.c

    libfoo.a : foo.o
    ar crv libfoo.a foo.o

    tst_a : tst.o foo.o
    $(CC) $(CFLAGS) -o tst_a tst.o foo.o


    tst_b : tst.o libfoo.a
    $(CC) $(CFLAGS) -o tst_b tst.o libfoo.a

    ::::::::::::::
    foo.c
    ::::::::::::::

    void foo( int n, float* a ){

    int i;

    for( i=0; i
    a[i] *= a[i];
    }
    }

    ::::::::::::::
    tst.c
    ::::::::::::::

    #include

    void foo( int n ,float* a );

    int main(){

    int i;
    int n = 256;

    float a[256];

    for( i=0; i a[i] = i;
    }

    printf( "%f \n" ,a[64] );

    foo( n ,a );

    printf( "%f \n" ,a[64] );

    }

    sun_x86%rhb {95} make tst_a
    cc -fast -xdepend=yes -xvector=simd -xarch=amd64 -c -o tst.o tst.c
    cc -fast -xdepend=yes -xvector=simd -xarch=amd64 -c -o foo.o foo.c
    cc -fast -xdepend=yes -xvector=simd -xarch=amd64 -o tst_a tst.o foo.o
    sun_x86%rhb {96} ./tst_a
    64.000000
    4096.000000
    sun_x86%rhb {97} make tst_b
    ar crv libfoo.a foo.o
    a - foo.o
    cc -fast -xdepend=yes -xvector=simd -xarch=amd64 -o tst_b tst.o libfoo.a
    ld: warning: file libfoo.a ignored: unable to locate archive symbol table
    Undefined first referenced
    symbol in file
    foo tst.o
    ld: fatal: Symbol referencing errors. No output written to tst_b
    make: *** [tst_b] Error 1
    sun_x86%rhb {98} file *.o
    foo.o: ELF 64-bit LSB relocatable AMD64 Version 1 [SSE CMOV]
    tst.o: ELF 64-bit LSB relocatable AMD64 Version 1 [SSE2 SSE]
    sun_x86%rhb {99}

  2. Re: Library link failure for -xarch=amd64 w/ Solaris 10 & Studio 11

    On 2008-05-17 15:57:09 +0100, Reginald Beardsley said:

    > cc -fast -xdepend=yes -xvector=simd -xarch=amd64 -o tst_b tst.o libfoo.a
    > ld: warning: file libfoo.a ignored: unable to locate archive symbol table
    > Undefined first referenced
    > symbol in file
    > foo tst.o
    > ld: fatal: Symbol referencing errors. No output written to tst_b


    I think you need to use something like "-z allextract" to be able to
    use .a files like that. I can't recall offhand if that's an ld flag, or
    a compiler flag.

    Alternatively, does ranlibbing the .a file help?

    Cheers,

    Chris


  3. Re: Library link failure for -xarch=amd64 w/ Solaris 10 & Studio11

    Chris Ridd wrote:
    > On 2008-05-17 15:57:09 +0100, Reginald Beardsley said:
    >
    >> cc -fast -xdepend=yes -xvector=simd -xarch=amd64 -o tst_b tst.o libfoo.a
    >> ld: warning: file libfoo.a ignored: unable to locate archive symbol table
    >> Undefined first referenced
    >> symbol in file
    >> foo tst.o
    >> ld: fatal: Symbol referencing errors. No output written to tst_b

    >
    >
    > I think you need to use something like "-z allextract" to be able to use
    > .a files like that. I can't recall offhand if that's an ld flag, or a
    > compiler flag.
    >
    > Alternatively, does ranlibbing the .a file help?
    >
    > Cheers,
    >
    > Chris
    >


    It's a linker flag. Neither "-z allextract" nor ranlib has any effect
    on the problem. If I use "-xarch=native" it links, but that produces
    32 bit object files. Every option that produces 64 bit objects fails at
    link time if the foo.o is coming from a library.

    rhb

  4. Re: Library link failure for -xarch=amd64 w/ Solaris 10 & Studio 11

    On 2008-05-17 17:42:15 +0100, Reginald Beardsley said:

    > It's a linker flag. Neither "-z allextract" nor ranlib has any effect
    > on the problem. If I use "-xarch=native" it links, but that produces
    > 32 bit object files. Every option that produces 64 bit objects fails
    > at link time if the foo.o is coming from a library.


    Does -lfoo change things? The linker also has a -64 flag which can
    force it into 64-bit mode.

    Cheers,

    Chris


  5. Re: Library link failure for -xarch=amd64 w/ Solaris 10 & Studio11

    Chris Ridd wrote:
    > On 2008-05-17 17:42:15 +0100, Reginald Beardsley said:
    >
    >> It's a linker flag. Neither "-z allextract" nor ranlib has any effect
    >> on the problem. If I use "-xarch=native" it links, but that produces
    >> 32 bit object files. Every option that produces 64 bit objects fails
    >> at link time if the foo.o is coming from a library.

    >
    >
    > Does -lfoo change things? The linker also has a -64 flag which can force
    > it into 64-bit mode.
    >
    > Cheers,
    >
    > Chris
    >


    I was doing -lfoo on a large build when I ran into the problem. This
    was the smallest, most demonstration case I could create. Adding
    -Wl,-64 has no effect. I tried that several hours before I posted my query.

    It looks as if the linker is examining the library entries and if the
    library entry uses a feature not present in the file containing main()
    it skips that library entry and ultimately, then returns the "not found"
    error.

    When I first encountered the problem, of the 8-10 library objects
    referenced, only those which file(1) listed as using x86 extensions were
    failing to resolve.

    If I add a function bar() which just calls printf(3c) and call it from
    main(), the reference to bar() gets resolved.

    Here's the file(1) output for the 3 objects:

    bar.o: ELF 64-bit LSB relocatable AMD64 Version 1
    foo.o: ELF 64-bit LSB relocatable AMD64 Version 1 [SSE CMOV]
    tst.o: ELF 64-bit LSB relocatable AMD64 Version 1 [SSE2 SSE]

    And the linker error and library contents:

    un_x86%rhb {206} make tst_b
    cc -fast -xdepend=yes -xvector=simd -xarch=generic64 -o tst_b tst.o libfoo.a
    Undefined first referenced
    symbol in file
    foo tst.o
    ld: fatal: Symbol referencing errors. No output written to tst_b
    make: *** [tst_b] Error 1
    sun_x86%rhb {207} ar tv libfoo.a
    rw-r--r-- 36820/10049 3136 May 17 12:32 2008 foo.o
    rw-r--r-- 36820/10049 2960 May 17 12:32 2008 bar.o
    sun_x86%rhb {208}
    `

  6. Re: Library link failure for -xarch=amd64 w/ Solaris 10 & Studio 11

    On Sat, 17 May 2008 16:49:54 +0100, Chris Ridd wrote:

    > On 2008-05-17 15:57:09 +0100, Reginald Beardsley said:
    >> cc -fast -xdepend=yes -xvector=simd -xarch=amd64 -o tst_b tst.o libfoo.a
    >> ld: warning: file libfoo.a ignored: unable to locate archive symbol table


    What exactlty IS libfoo.a...? How was it made?
    I cant find the original post but then i see 2 threads with the same
    Subject : <

    Apparently libfoo is not a 64 bit "current ar archive" as 'file' would
    report. Either that or ld cant find it ; /

    >> Undefined first referenced
    >> symbol in file
    >> foo tst.o
    >> ld: fatal: Symbol referencing errors. No output written to tst_b

    > I think you need to use something like "-z allextract" to be able to
    > use .a files like that. I can't recall offhand if that's an ld flag, or
    > a compiler flag.
    > Alternatively, does ranlibbing the .a file help?


    ranlib is a script - on SPARC anyway - and is basically a NOP
    containing exit 0; The only time Ive ever used allextract is to convert
    static libs to shared. Perhaps it has other uses.


  7. Re: Library link failure for -xarch=amd64 w/ Solaris 10 & Studio11

    Reginald Beardsley wrote:
    > I'm trying to figure out what commandline options I need to use to link
    > properly for the AMD64 architecture.
    >
    > If I link a bunch of object files it works fine. However, if I try to
    > link the same objects from a library it fails. The problem seems to be
    > related to the tagging of architecture dependencies in the library. It
    > doesn't happen unless I use -xarch=amd64 or xarch=amd64a.
    >

    Have you tried Studio 12? 64 bit building has been simplified with the
    -m64 option.

    --
    Ian Collins.

  8. Re: Library link failure for -xarch=amd64 w/ Solaris 10 & Studio11

    Ian Collins wrote:
    > Reginald Beardsley wrote:
    >
    >>I'm trying to figure out what commandline options I need to use to link
    >>properly for the AMD64 architecture.
    >>
    >>If I link a bunch of object files it works fine. However, if I try to
    >>link the same objects from a library it fails. The problem seems to be
    >>related to the tagging of architecture dependencies in the library. It
    >>doesn't happen unless I use -xarch=amd64 or xarch=amd64a.
    >>

    >
    > Have you tried Studio 12? 64 bit building has been simplified with the
    > -m64 option.
    >


    Not yet. I've downloaded Solaris 10 5/08 & Studio 12 and will be
    building a new system image shortly. I ran into this trying to build
    some software for a client.

    It just seems to me impossible that it doesn't work in Studio 11. I
    assumed I'm missing something obvious. Or at least I did until I'd sunk
    3-4 hours into trying to find an answer documented somewhere. Whatever
    the answer is, I don't think it's obvious anymore :-( The patch for
    Studio 11 lists lots of things it fixes, but this is not among them.

    rhb

+ Reply to Thread