First Last Prev Next    No search results available
Details
: ppw "make check" failure with sun compilers
Bug#: 193
: Parallel Performance Wizard
: Build system
Status: ASSIGNED
Resolution:
: All
: All
: 2.6
: P2
: normal
: 2.6.1

:
:
:
:
  Show dependency tree - Show dependency graph
People
Reporter: Paul H. Hargrove <PHHargrove@lbl.gov>
Assigned To: Max Billingsley III <billingsley@hcs.ufl.edu>
:

Attachments


Note

You need to log in before you can comment on or make changes to this bug.

Related actions
Votes: 0


Description:   Opened: 2010-12-04 16:47
This has been seen with both v2.4 and v2.6, but there is no '2.6' in the
Version list on Bugzilla yet.

When using the Sun Studio 12.1 or Solaris Studio 12.2 (Oracle changed the name
between versions) compilers to build I get a link failure from "make check".  I
see this on all platforms I have access to, including Solaris 10 SPARC, Solaris
10 x86, OpenSolaris x86, OpenSolaris x86-64 and Linux/x86-64.

Note that one can get the Studio 12.2 compilers for Linux as a free download
from sun/oracle.


$ make check
[...]
Making check in src
gmake[1]: Entering directory `/export/home/phargrov/ppw-2.6/src'
gmake  test1 test2 test3 test4 test5 test6 test7 test8 test9 test10 ptfdump
ppwbench ppwtar-bin ppwident-bin
gmake[2]: Entering directory `/export/home/phargrov/ppw-2.6/src'
source='test1.c' object='test1-test1.o' libtool=no \
DEPDIR=.deps depmode=none /usr/bin/bash ../depcomp \
/usr/local/solstudio12.2/bin/suncc -DHAVE_CONFIG_H -I.  -DPPW_SEQ=1 
-I/export/home/phargrov/ppw-2.6/gasnet-tools
-I/export/home/phargrov/ppw-2.6/gasnet-tools/other
-I/export/home/phargrov/ppw-2.6/gasnet-tools  -g -c -o test1-test1.o `test -f
'test1.c' || echo './'`test1.c
/usr/local/solstudio12.2/bin/suncc  -g 
-L/export/home/phargrov/ppw-2.6/gasnet-tools -o test1 test1-test1.o
libppw_meas-seq.a -lgasnet_tools-seq libppw_gasp_cprof_upcall-seq.a
Undefined                       first referenced
 symbol                             in file
sched_yield                        
/export/home/phargrov/ppw-2.6/gasnet-tools/libgasnet_tools-seq.a(gasnet_tools.o)
ppw_struct_pack_be                 
libppw_meas-seq.a(libppw_meas_seq_a-ppw_io_struct.o)
ppw_gasp_lookupsrc                  test1-test1.o
ld: fatal: Symbol referencing errors. No output written to test1
gmake[2]: *** [test1] Error 2
gmake[2]: Leaving directory `/export/home/phargrov/ppw-2.6/src'
gmake[1]: *** [check-am] Error 2
gmake[1]: Leaving directory `/export/home/phargrov/ppw-2.6/src'
gmake: *** [check-recursive] Error 1


The sched_yield() symbol is only undefined on Solaris 10, because one needs
"-lposix4" when using GASNet tools on this platform.  With a full GASNet that
would be expressed in a .mak file, but there is nothing of the sort provided by
GASNet Tools.  I will enter a GASNet bug report for that issue.

I have looked into this and can account, sort of, for both undefined ppw_*
symbols.  It seems that the way the "inline" keyword is being used is causing
these.  I am not clear if this is a portability problem in PPW or a compiler
bug.

In the case of ppw_gasp_lookupsrc() the problem is the following in
src/ppw_meas.h:

static inline int32_t ppw_meas_srcid(ppw_meas meas,
    unsigned int gasp_tag, const char *filename, int line,
    char is_local, const void *data) {
[...]
  newid = (int32_t)ppw_gasp_lookupsrc(meas->pdata,
      gasp_tag, filename, line, is_local, data);

[...]
}

Even though this is marked "static inline" is appears that the Sun compiler is
including a copy of ppw_meas_srcid() in each object that has included
ppw_meas.h (as can be verified with nm), even though the function is not called
from that object.  The result is the undefined reference to
ppw_gasp_lookupsrc().

For the case of ppw_struct_pack_be() the function is an inline in
src/ppw_io_struct.c and is used ONLY in that file.  However, it seem that the
compiler has done something stupid and is NOT inlining it and NOT including a
copy in the object.  Changing "inline" to "static inline", or removing
"inline", for that one function appears to resolve this problem, but this seems
to be a compiler bug as far as I can tell.

Here is the Linux failure which has no problem w/ sched_yield(), but provides
more info regarding the two undefined ppw_* symbols, which supports my
explanation of the problem above.

make[1]: Entering directory `/home/phargrov/tmp/ppw-2.6/src'
make  test1 test2 test3 test4 test5 test6 test7 test8 test9 test10 ptfdump
ppwbench ppwtar-bin ppwident-bin
make[2]: Entering directory `/home/phargrov/tmp/ppw-2.6/src'
source='test1.c' object='test1-test1.o' libtool=no \
        DEPDIR=.deps depmode=none /bin/bash ../depcomp \
        /opt/SS12u2/solstudio12.2/bin/suncc -DHAVE_CONFIG_H -I.  -DPPW_SEQ=1 
-I/home/phargrov/tmp/ppw-2.6/gasnet-tools
-I/home/phargrov/tmp/ppw-2.6/gasnet-tools/other
-I/home/phargrov/tmp/ppw-2.6/gasnet-tools  -g -c -o test1-test1.o `test -f
'test1.c' || echo './'`test1.c
/opt/SS12u2/solstudio12.2/bin/suncc  -g 
-L/home/phargrov/tmp/ppw-2.6/gasnet-tools -o test1 test1-test1.o
libppw_meas-seq.a -lgasnet_tools-seq libppw_gasp_cprof_upcall-seq.a 
test1-test1.o: In function `ppw_meas_srcid':
/home/phargrov/tmp/ppw-2.6/src/./ppw_meas.h:310: undefined reference to
`ppw_gasp_lookupsrc'
libppw_meas-seq.a(libppw_meas_seq_a-ppw_malloc.o): In function
`ppw_meas_srcid':
/home/phargrov/tmp/ppw-2.6/src/./ppw_meas.h:310: undefined reference to
`ppw_gasp_lookupsrc'
libppw_meas-seq.a(libppw_meas_seq_a-ppw_list.o): In function `ppw_meas_srcid':
/home/phargrov/tmp/ppw-2.6/src/./ppw_meas.h:310: undefined reference to
`ppw_gasp_lookupsrc'
libppw_meas-seq.a(libppw_meas_seq_a-ppw_error.o): In function `ppw_meas_srcid':
/home/phargrov/tmp/ppw-2.6/src/./ppw_meas.h:310: undefined reference to
`ppw_gasp_lookupsrc'
libppw_meas-seq.a(libppw_meas_seq_a-ppw_io.o): In function `ppw_meas_srcid':
/home/phargrov/tmp/ppw-2.6/src/./ppw_meas.h:310: undefined reference to
`ppw_gasp_lookupsrc'
libppw_meas-seq.a(libppw_meas_seq_a-ppw_io_buffered.o):/home/phargrov/tmp/ppw-2.6/src/./ppw_meas.h:310:
more undefined references to `ppw_gasp_lookupsrc' follow
libppw_meas-seq.a(libppw_meas_seq_a-ppw_io_struct.o): In function
`ppw_struct_unpack':
/home/phargrov/tmp/ppw-2.6/src/ppw_io_struct.c:419: undefined reference to
`ppw_struct_pack_be'
/home/phargrov/tmp/ppw-2.6/src/ppw_io_struct.c:427: undefined reference to
`ppw_struct_pack_be'
/home/phargrov/tmp/ppw-2.6/src/ppw_io_struct.c:439: undefined reference to
`ppw_struct_pack_be'
/home/phargrov/tmp/ppw-2.6/src/ppw_io_struct.c:454: undefined reference to
`ppw_struct_pack_be'
libppw_meas-seq.a(libppw_meas_seq_a-ppw_io_struct.o): In function
`ppw_struct_pack':
/home/phargrov/tmp/ppw-2.6/src/ppw_io_struct.c:512: undefined reference to
`ppw_struct_pack_be'
libppw_meas-seq.a(libppw_meas_seq_a-ppw_io_struct.o):/home/phargrov/tmp/ppw-2.6/src/ppw_io_struct.c:520:
more undefined references to `ppw_struct_pack_be' follow
libppw_gasp_cprof_upcall-seq.a(libppw_gasp_cprof_upcall_seq_a-gasp_cprof_upcall.o):
In function `ppw_meas_srcid':
/home/phargrov/tmp/ppw-2.6/src/./ppw_meas.h:310: undefined reference to
`ppw_gasp_lookupsrc'
make[2]: *** [test1] Error 2
make[2]: Leaving directory `/home/phargrov/tmp/ppw-2.6/src'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/home/phargrov/tmp/ppw-2.6/src'
make: *** [check-recursive] Error 1
------- Comment #1 From Paul H. Hargrove 2010-12-04 17:50:15 -------
Playing with various flags in the suncc manpage I find that configuring with
    CC='suncc -features=no%extinl'
can resolve the problem with ppw_struct_pack_be().  The documentation states
that the default behavior w/o this flag conforms to the ISO/IEC 9899:1999 C
standard, thus suggesting that the default behavior with respect to
ppw_struct_pack_be() is the correct one.  However, I don't think that is the
case.

This flag doesn't make any difference for the unresolved ppw_gasp_lookupsrc().
------- Comment #2 From Max Billingsley III 2010-12-15 16:20:23 -------
I'm now looking into this issue...
------- Comment #3 From Max Billingsley III 2011-02-03 18:45:17 -------
Well I had put this issue aside for a bit but decided to look into it further.

I looked into this using Oracle Solaris Studio 12.2 on Linux.

I fixed the unresolved reference to ppw_struct_pack_be() by simply marking this
function 'static inline' -- perhaps should try to see if this issue really was
due to a compiler bug, but alas, I don't really have the time atm...

Regarding the ppw_gasp_lookupsrc() issue, as Paul says, it looks we are getting
ppw_meas_srcid() in objects being built from files including ppw_meas.h, for
example test1.c, even though that function is not called from that object. 
However, we have no definition of ppw_gasp_lookupsrc() in any object that is
being linked when building the test programs.

I think we can't assume the compiler will NOT include ppw_meas_srcid(), so we
need to go ahead and provide a library so that the ppw_gasp_lookupsrc()
reference can be resolved.  I've tweak the build system so that
libppw_gasp_cprof-seq.a gets linked in... which certainly seems logical enough
anyway since the corresponding libppw_gasp_cprof_upcall-seq.a was already being
linked in.

NOTE: I still haven't looked into the issue with sched_yield() on Solaris -- I
plan to do that shortly.  I think the only option there for now will be a
Solaris-specific "workaround" in the build system.
------- Comment #4 From Paul H. Hargrove 2012-05-23 02:22:14 -------
As Max commented in Feb 2011, he made changes to the build system which
appeared in PPW-2.8 and resolved all but the undefined sched_yield which is
specific to Solaris (and not present on Solaris 11 if I an remembering
correctly).

I have been able to work around that in my own builds of PPW-2.8 with
   $ make check LIBS=-ltr
and similarly adding LIBS=-ltr if ever compiling with the problematic files.

I am testing the PPW-3.0 release now, but my Solaris-10 machines are not the
fastest things around.  So, it may take awhile.
------- Comment #5 From Paul H. Hargrove 2012-05-23 02:38:08 -------
OK... that should have been "LIBS=-lrt" (not "tr") in my previous comment.

Tests on Solaris-10 show the undefined sched_yield() problem still exists in
PPW-3.0.  I also find that my work-around still works (when spelled correctly).

I also tested adding "LIBS=-lrt" to the configure command line.
I found this approach works at least as well as adding to the make command
line.
Since adding to LIBS at configure time needs only to be done ONCE, it is now my
recommended work-around.

-Paul

First Last Prev Next    No search results available