[Trilinos-Users] [EXTERNAL] Re: Trilinos Build Problem

Gary.Myers.Contractor at unnpp.gov Gary.Myers.Contractor at unnpp.gov
Mon Jan 20 11:05:14 MST 2014


I am in the process of getting the full verbose compile over to our
computers which interface with the internet.

In the meantime, I have successfully built and test teuchos by itself
from Trilinos 11.4.2.  Then I attempted to just build and test teuchos
and sacado.  This attempt failed in the manner that was consistent with
what I have been getting with the full build.  I looked at the
Teuchos_config.h file and the TEUCHOSCORE_LIB_DLL_EXPORT macros is not

Now, there is a possibility that my environmental pathnames could be
pulling in an older version.  Let me check into this and see if this is
causing an issue.  

I will get back to you on this.



-----Original Message-----
From: Perschbacher, Brent M [mailto:bmpersc at sandia.gov] 
Sent: Monday, January 20, 2014 12:29 PM
To: Myers, Gary T (Contractor); bundeka at id.doe.gov;
trilinos-users at software.sandia.gov
Subject: Re: [EXTERNAL] Re: [Trilinos-Users] Trilinos Build Problem

  That macro being empty is fine, in fact it is expected to be empty
more often than not. However, the error in question is stating that the
macro isn't defined, even as empty. Since the preprocessor didn't
replace it the compiler is trying to figure it out based on context and
isn't able to.
Getting the build files from you would help greatly specifically the
full verbose compile line and error message. I'm not sure if this is the
cause of your issues, but do you have a previously installed copy of
Trilinos somewhere on your machine? Some versions of linux have been
distributing older versions of Trilinos for a while now. It is possible
that an older copy of Teuchos_DLLExport_Macro.h is being picked up
instead of the copy in your source tree. When teuchos was refactored
into subpackages that file was changed to no longer be a generated file,
but instead to use a static copy. This was the solution we settled on
for teuchos when we discovered how the subpackages interacted with our
windows DLL build.


On 1/17/14 10:15 AM, "Gary.Myers.Contractor at unnpp.gov"
<Gary.Myers.Contractor at unnpp.gov> wrote:

>Brent and Kermit,
>Thanks for the suggestions.  Although its goes against what I want in 
>my final product, I did set BUILD_SHARED_LIBS to OFF.  However, I still

>get a similar error in Teuchos.  In either case for BUILD_SHARED_LIBS, 
>I think TEUCHOSCORE_LIB_DLL_EXPORT is being defined, but as an empty 
>macro.  However, because this macro is being used in some declarations,

>it is producing compiling errors. It's not clear to me how I am digging

>myself into this hole, so I am in the process of getting output files 
>over to a computer so I can share with everyone.  In the mean time, 
>here is my configuration command line which I am typing into this 
>e-mail (so there may be some typos). Because many items are referenced 
>from nonstandard areas, they need to be explicitly defined in the cmake

>	-D CMAKE_INSTALL_PREFIX:PATH (path name here) \
>	-D Trilinos_ENABLE_Fortran:BOOL=ON \
>	-D MPI_BASE_DIR:PATH= (path name here) \	
>	-D MPI_EXEC:FILEPATH= (path name here) \
>	-D MPI_C_COMPILER:FILEPATH= (path name to openmpi 1.4.5 mpicc) \
>	-D MPI_CXX_COMPILER:FILEPATH= (path name to openmpi 1.4.5
>mpicxx) \
>	-D MPI_Fortran_COMPILER:FILEPATH= (path name to openmpi 1.4.5
>mpif90) \
>	-D Boost_LIBRARY_DIRS:PATH= (path name here) \
>	-D Boost_INCLUDE_DIRS:PATH= (path name here) \
>	-D MKL_LIBRARY_DIRS:FILEPATH= (path name to intel64 libraries) \
>	-D MKL_INCLUDE_DIRS:FILEPATH= (path name to intel64 includes) \
>	-D Netcdf_INCLUDE_DIRS:PATH= (path name) \
>	-D Netcdf_LIBRARY_DIRS:PATH= (path name) \
>	-D Matio_INCLUDE_DIRS:PATH= (path name) \
>	-D Matio_LIBRARY_DIRS:PATH= (path name) \
>	-D PYTHON_EXECUTABLE:FILEPATH= (path name to python 2.7.5) \
>	-D PYTHON_INCLUDE_DIRS:PATH= (path name to python 2.7.5
>includes) \
>	-D PYTHON_LIBRARIES:PATH= (path list to python 2.7 libraries) \
>	-D BLAS_LIBRARY_DIRS:PATH= (path to intel64 library ) \
>	-D LAPACK_LIBRARY_DIRS:PATH= (path to intel64 library ) \
>	(path name to source distribution for trilinos 11.4.2)
>Error occurs in line 82 of Teuchos_ScalarTraits.hpp - this declaration 
>has no storage class or type specifier
>Error occurs in line 83 of Teuchos_ScalarTrailts.hpp - expected a ;
>	Void throwScalarTraitsNanInfError( const std::string &errMsg );
>. . . . etc. . . .
>Please note that if I disable Teuchos I am successful, but then I lose 
>too many other packages which are important to me.  Any additional 
>guidance of how I can dig out of this hole would be great.
>Gary T. Myers
>Principal Scientist
>Bechtel Marine Propulsion Corp.
>Gary.Myers.contractor at unnpp.gov
>-----Original Message-----
>From: Perschbacher, Brent M [mailto:bmpersc at sandia.gov]
>Sent: Thursday, January 16, 2014 4:00 PM
>To: Myers, Gary T (Contractor); bundeka at id.doe.gov; 
>trilinos-users at software.sandia.gov
>Subject: Re: [EXTERNAL] Re: [Trilinos-Users] Trilinos Build Problem
>  You really don't want to force _WIN32 to be set if you aren't on a 
>windows machine creating a shared build. That macro is used to specify 
>which classes/functions will be publicly available inside DLL's.
>However, it should be defined but as empty on non-windows machines. The

>last few lines of the Teuchos_DLLExportMacro.h should have that 
>assignment to empty. I have an idea what might be causing this, but I'm

>not sure why it wouldn't have caused us trouble before if it is the 
>case. I will look into it. In the mean time you can either build a 
>static build (ie don't set BUILD_SHARED_LIBS to ON) or you could add 
>the empty define manually with CMAKE_CXX_FLAGS and CMAKE_C_FLAGS.
>On 1/16/14 1:30 PM, "Gary.Myers.Contractor at unnpp.gov"
><Gary.Myers.Contractor at unnpp.gov> wrote:
>>Yes, I already have this set.  But, I feel that _WIN32 is not set 
>>(which my intuition suggest is correct) since I am not on a WIN 32 
>>based computer.  I am on a Linux 64 bit cluster.  I guess I could 
>>_WIN32 to be defined and see what happens.
>>-----Original Message-----
>>From: Bunde, Kermit A [mailto:bundeka at id.doe.gov]
>>Sent: Thursday, January 16, 2014 3:02 PM
>>To: Myers, Gary T (Contractor)
>>Subject: RE: [Trilinos-Users] Trilinos Build Problem
>>Please ignore my last reply.  In doing a little google searching:
>>http://msdn.microsoft.com/en-us/library/b0084kay.aspx lists
>>_WIN32 as a predefined macro.
>>Try adding this to your do_configure script:
>>Kermit Bunde
>>Enforcement Coordinator
>>Criticality Safety SME
>>Nuclear Safety SME
>>DOE-ID Aviation Safety Officer
>>208-526-5188 (office)
>>208-526-1926 (fax)
>>208-680-6843 (cell)
>>"Accept the challenges so that you may feel the exhilaration of 
>>Never tell people how to do things. Tell them what to do and they will

>>surprise you with their ingenuity."
>>--George S. Patton Jr.,
>>American Army general
>>From: trilinos-users-bounces at software.sandia.gov
>>[mailto:trilinos-users-bounces at software.sandia.gov] On Behalf Of 
>>Gary.Myers.Contractor at unnpp.gov
>>Sent: Thursday, January 16, 2014 8:42 AM
>>To: trilinos-users at software.sandia.gov
>>Subject: [Trilinos-Users] Trilinos Build Problem
>>Newbie question here: First time build of Trilinos using CMake.
>>I am building Trilinos 11.4.2 on a Linux Cluster using Intel 
>>openMPI, MKL, . . .
>>CMake configuration is completed, but Teuchos fails  to compile 
>>macro TEUCHOSCORE_LIB_DLL_EXPORT is not explicitly define.  The first 
>>reference occurs on line 82 of Teuchos_ScalarTraits.hpp.
>>In looking at Teuchos_DLLExportMacro.h, I could see how this could 
>>happen since _WIN32 probably is not defined.
>>Can someone suggest how I can get past this (please note that I am not

>>in a position to easily share files since the Linux Cluster is not on 
>>the grid)?
>>Gary T. Myers
>>Principal Scientist
>>Bechtel Marine Propulsion Corp.
>>Gary.Myers.contractor at unnpp.gov
>>Trilinos-Users mailing list
>>Trilinos-Users at software.sandia.gov

More information about the Trilinos-Users mailing list