Comments you submit will be routed for moderation. If you have an account, please log in first.
Modify

Ticket #4282 (closed defect: fixed)

Opened 5 years ago

Last modified 5 years ago

acro-colin build fails linking coliny

Reported by: jdsiiro Owned by: wehart
Priority: blocker Milestone: Colin 3.0
Component: Acro Admin Version:
Keywords: Cc: acro-developers@…
Subcomponent: Configuration and Building

Description

r6060 appears to have introduced a bug into the build logic:

  • interfaces/trunk/src/Makefile.am

    a b  
    7373PEBBLLIB=$(top_builddir)/packages/pebbl/src/libpebbl.a 
    7474endif 
     75if BUILD_SCOLIB 
     76PEBBLLIB=$(top_builddir)/packages/scolib/src/libscolib.a 
     77endif 
    7578 
    7679#$(top_builddir)/packages/coliny/src/libcoliny.a 
    7780 
    7881LDADD_ACRO_LIBS = $(top_builddir)/packages/interfaces/src/libinterfaces.a\ 
     82        $(SCOLIB)\ 
    7983        $(top_builddir)/packages/colin/src/libcolin.a\ 
    8084        $(PEBBLLIB)\ 

However, if I get a clean checkout of acro-colin/trunk and change the questionable line 76 to set SCOLIB, the resulting system fails to build. If compiled in serial, the link step for producing the coliny executable returns:

coliny.o: In function `main':
../../../packages/utilib/src/.libs/libutilib.a(libutilib_la-Serialize.o): In function `char* std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_S_construct<__gnu_cxx::__normal_iterator<char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >(__gnu_cxx::__normal_iterator<char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, __gnu_cxx::__normal_iterator<char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<char> const&, std::forward_iterator_tag)':
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/basic_string.tcc:158: undefined reference to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_Rep::_M_set_length_and_sharable(unsigned int)'
../../../packages/utilib/src/.libs/libutilib.a(libutilib_la-TypeManager.o): In function `char* std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_S_construct<__gnu_cxx::__normal_iterator<char const*, std::vector<char, std::allocator<char> > > >(__gnu_cxx::__normal_iterator<char const*, std::vector<char, std::allocator<char> > >, __gnu_cxx::__normal_iterator<char const*, std::vector<char, std::allocator<char> > >, std::allocator<char> const&, std::forward_iterator_tag)':
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/basic_string.tcc:158: undefined reference to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_Rep::_M_set_length_and_sharable(unsigned int)'
../../../packages/utilib/src/.libs/libutilib.a(libutilib_la-TypeManager.o): In function `std::basic_string<char, std::char_traits<char>, std::allocator<char> >& std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_replace_dispatch<__gnu_cxx::__normal_iterator<char const*, std::vector<char, std::allocator<char> > > >(__gnu_cxx::__normal_iterator<char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, __gnu_cxx::__normal_iterator<char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, __gnu_cxx::__normal_iterator<char const*, std::vector<char, std::allocator<char> > >, __gnu_cxx::__normal_iterator<char const*, std::vector<char, std::allocator<char> > >, __false_type)':
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/basic_string.tcc:641: undefined reference to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_check_length(unsigned int, unsigned int, char const*) const'
collect2: ld returned 1 exit status

If compiled in parallel (-j2), the build process dies in scolib, claiming that it doesn't know how to create libscolib.a (required by a dependency).

Steps to reproduce:

svn co https://software.sandia.gov/svn/public/acro/acro-colin/trunk test-build
cd test-build
(edit packages/interfaces/src/Makefile.am)
./setup
./setup configure
make

Attachments

Change History

comment:1 Changed 5 years ago by jdsiiro

More info: The culprit appears to be the FLIBS variable. It is set (by autoconf) to be:

FLIBS= -L/usr/lib/gcc/i386-redhat-linux/3.4.6 -L/usr/lib/gcc/i386-redhat-linux/3.4.6/../../.. -lfrtbegin -lg2c -lm

The problem arises because autoconf picked up the default g++ compiler on the system (g++ 4.1.2). The version mismatch between 3.4.6 and 4.1.2 appears to be the root cause of the problem. It is not obvious to me why we are including FLIBS in the APPSPACKLIB variable (see packages/interfaces/src/Makefile.am), as coliny builds cleanly without it.

comment:2 Changed 5 years ago by jdsiiro

  • Summary changed from acro-colin parallel build fails linking coliny to acro-colin build fails linking coliny

The confusion appears to stem from the fact that I have both

  • gcc-gfortran-4.1.2-42.el5
  • compat-gcc-34-g77-3.4.6-4

installed. Apparently, autoconf is finding the g77 compatibility libraries when it is configuring the f77 flags, but is finding the main gcc 4.1.2 for everything else.

comment:3 Changed 5 years ago by jdsiiro

  • Cc lafisk added

r6066 is my attempt at fixing the build issues that I am seeing. Someone who actually understands the Acro autoconf system needs to review these changes (and the ticket history) before closing this ticket.

comment:4 Changed 5 years ago by lafisk

  • Status changed from new to closed
  • Resolution set to fixed

These changes look good to me. The last time I checked appspack had only one fortran file and it was not part of the library, so leaving off FLIBS is ok. I'll close this ticket.

comment:5 Changed 5 years ago by wehart

  • Cc acro-developers@… added; lafisk removed

I had a similar experience recently, where there was a bad fortran installation. Given the significant complexity of diagnosing these issues, I propose the following Acro management policy:

  • FORTRAN codes are disabled by default in Acro, but they can be enabled in the configuration line.

I don't think that this would necessary lead to greater instability in our ability to build with these codes. We would still have nightly tests that exercised the FORTRAN codes. BUT, it would protect the development team from dealing with these crazy issues on a regular basis.

--Bill

View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.