Originally posted by: brianpiper

I was hoping I could get some help or some insight for compiling CPLEX using the PGI (http://www.pgroup.com) compilers. I am not an expert in Linux and C++, but hopefully I can explain myself well enough to get some help.

I am using Cplex 12.4, C++ Concert API, and CentOS 6.4 on a 64 bit machine. Apparently, this is not one of Cplex's supported compilers, because when compiling using essentially the makefile that comes with CPLEX, I get an error like this:

/opt/ibm/ILOG/CPLEX_Studio124/cplex/include/ilcplex/cpxconst.h", line 98: catastrophic error:

Looking at the header, I saw that if I added compile symbols __GNUC__ and _LP64, with the flags "-D__GNUC__" and "-D_L64", I could compile my program, but linking was a problem for some reason (linking works fine with the g++ compiler and Cplex on this machine). Here is an example of the linker error:

I tried to see if the there was somewhere else where the GNUC symbol was used, and after a quick "grep", I saw that I might want to define it as "-D__GNUC__=4", "-D__GNUC_MINOR=4" (this is the gnu c++ version on the machine), which MIGHT be fine with the PGI compilers, because they are (possibly) compatible with g++ in some way, but that resulted in a whole host of additional issues during compilation, like so:

Does anyone have experience using the PGI compilers to compile Cplex? Any ideas what else I might try? Thank you in advance for any help you can provide.

You are right, these compilers are unsupported.

I take it you are trying to use the 64bit Linux port for CPLEX? If so then I think it would be better to compile with -DCPXSIZE_BITS=64 instead of -D__GNUC__ or anything like this. This should give you the correct definitions.

I am not sure whether the linker problems with C++ code can be fixed. Could you please try the following:

• Go to directory /opt/ibm/ILOG/CPLEX_Studio124/cplex/examples/x86-64_sles10_4.1/static_pic/
• Edit Makefile: add -DCPXSIZE_BITS=64 to the definition of the CCC variable.
• Run make blend. If that fails then please post the full command lines and output for compilation and linking here.

Originally posted by: brianpiper

Thank you for the speedy reply!

You are correct about that I am trying to use the 64bit Linux port for CPLEX. I added the flag -DCPXSIZE_BITS=64 as you suggested... but I had a few more errors. I'll put them out one at a time, and some changes I made along the way to try to overcome them, though I am rather pessimistic about the changes I made after the first thing failed being a good idea, never mind if they're even valid. 

1. In examples directory, compiling with pgc++ -DCPXSIZE_BITS=64

  pgc++ -O0 -DCPXSIZE_BITS=64 -c -m64 -O -fPIC -fno-strict-aliasing -fexceptions -DNDEBUG -DIL_STD  -I../../../include -I../../../../concert/include  ../../../examples/src/cpp/blend.cpp -o blend.o

2. At this point, I remembered that I had removed those flags for the compilation I showed earlier and tried to find alternatives in the pgc++ compiler. The flag -fexceptions doesn't seem to be a problem, pgcpp has exception handling enabled by default, but I changed -fexceptions to --exceptions anyway. For -fno-strict-aliasing, things are murkier to me. It can compile at least without that flag. pgcpp has a flag, -alias, which can be set as follows:

ansi: Enable optimizations using ANSI C type-based pointer disambiguation

traditional: Disable type-based pointer disambiguation

3. Sorry to add to the issues with item #2 but when I realized I had done that, I thought there might something I did wrong that would be obvious. Now, onto the linking. Here is the output, which is pretty long and looks fairly repetitive to me. This is with -alias=traditional, which I think might be analogous to -fno-strict-aliasing. Or maybe not, let me know what you think!

$ make blend

aliasing is only related to optimization. No matter what value you choose for this option should not cause linker errors.

The linker errors you see are most likely related to an incompatibility between your C++ compiler and g++: Compilers are free to choose in which way they mangle C++ function names into symbol names and it looks like your compiler uses a different name mangling than g++. Consider this error message:

This error is triggered by this source code line in blend.cpp

nm = IloNumArray(env, nbElements, 22.0, 10.0, 13.0);

When I compile this on 64bit Linux and look at the generated symbols then I get

djunglas@... examples/x86-64_sles10_4.1/static_pic> nm --demangle blend.o | grep IloNumArray::
                 U IloNumArray::IloNumArray(IloEnv, long, double)
                 U IloNumArray::IloNumArray(IloEnv, long, double, IloVarArgsNum, ...

So the symbol generated for this constructor by g++ looks something like IloNumArray::IloNumArray ... and this is the symbol that is provided by the libraries shipped with CPLEX.

From the linker error message it seems as if your compiler generates a symbol reference like IloNumArray::__ct ... for this constructor call. This symbol is then of course not found in the CPLEX libraries. Does your compiler have an option that instructs it to use a name mangling that is compatible with g++? If not then the only way out I see would be manually renaming all symbols appropriately. This would be quite painful and I am not even sure it will work.

According to this page adding --gnu to the compiler/linker flags or using pgc++ instead of pgcpp may resolve the linker issues. Can you please try that?

Originally posted by: brianpiper

Thank for you the link and the suggestion! That seems to have really cut down on the errors. Here is what I get now, but this looks like something I can handle. 

At this point, I figured I could get this in shape. I don't know why it didn't like "IloInfinity," my first response was to change that to 1.0E+20, because of what I found in cpxconst.h, and just commented out the "try...catch" block (leaving all the code the block contained). It compiled and linked, and ran successfully.  I tried out ilomipex1, and got a similar error, but I was able to compile and run when I removed the exception issue and when I made sure that all variables have an explicit upper and lower bound given.

In ilosys.h there is this definition of IloInfinity:

if (defined(ILO_LINUX) || defined(ILO_APPLE)) && !defined(ILO_RS6000)
#define IloInfinity __builtin_inf()
#elif defined(ILO_MSVC)
#define IloInfinity HUGE_VAL
#else
#define IloInfinity  (IloGetInfinity())
#endif

I guess you are in the first branch. If you are willing to edit this file you could try to replace __builtin_inf() by (1.0/0.0) (node the parenthesis and the floating point constants), or by anything else that results in IEEE infinity. What should work in any case (but is not as efficient) is to replace __builtin_inf() by IloGetInfinity(). Or just use IloGetInfinity() of IloInfinity. As long as you use only CPLEX as solver using 1e20 as infinity is also correct.

Searching for the exception message on the internet I found this. From that email thread I conclude that the problem is with the -fPIC command line option. Can you please try to remove -fPIC from CCOPT in the Makefile, delete the object files and try to build again?

Originally posted by: brianpiper

Thank you again for your persistence. I am happy to report that the examples compile/link/run perfectly now, as does my own program. I used "#define IloInfinity (1.0/0.0)", as well as remove the -fPIC flag. Thank you again for your help, I really appreciate it!