b3em
commented
7 years ago I've tested the latest release on rhel72 and cppgen no longer has a dependency on libstdc++.a so this error should be gone. libstdc++.a is still required though by other components and should be part of your toolchain.
I'm compiling from tag OSPL_V6_4_OSS_RELEASE on a RHEL-7 machine: $ uname -a Linux build 3.10.0-123.el7.x86_64 #1 SMP Mon May 5 11:16:57 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux $ source configure <I selected "x86_64.linux-release"> GCC: OK - using version 4.8.2 NOTE: enabling link-time optimizations in release build GLIBC: version 2.17 MAKE: OK - using GNU Make 3.82 Perl: OK - using perl version='5.16.3'; Qt: On. Using QT tools from the path (with -qt4 suffix). GAWK: OK - using GNU Awk 4.0.2 BISON: OK - using bison (GNU Bison) 2.7 FLEX: OK - using 2.5.37 JAVAC: Warning - you should set JAVA_COMPATJAR to rt.jar for Java 1.6 OK - using JAVAC version 1.7.0_51 JAVA_HOME is /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.51-2.4.5.5.el7.x86_64 GMCS: Warning - No gmcs compiler found gmcs C# compiler not found, disabling SACS api build. TAO: Warning - No TAO found TAO environment not set, disabling TAO related features. JACORB: Warning - JACORB_HOME not set JACORB environment not set, disabling JACORB related features. GSOAP: Warning - Not found, cmsoap will not be built Doxygen: OK Configuration OK
Variable Setup SPLICE_TARGET = x86_64.linux-release SPLICE_HOST = x86_64.linux-release OSPL_HOME = /home/cornell/apt/opensplice SPLICE_ORB = $ make ... make -C /home/cornell/apt/opensplice/src/tools/cppgen/ make[4]: Entering directory
/home/cornell/apt/opensplice/src/tools/cppgen' make[5]: Entering directory/home/cornell/apt/opensplice/src/tools/cppgen/bld/x86_64.linux-release' make[5]: stat: libstdc++.a: Too many levels of symbolic links ln -sfg++ -m64 -print-file-name=libstdc++.amake[5]: stat: libstdc++.a: Too many levels of symbolic links g++ -static-libgcc -L/home/cornell/apt/opensplice/lib/x86_64.linux-release -D_GNU_SOURCE -DOSPL_LINUX -O4 -fno-strict-aliasing -flto -DNDEBUG -Wall -W -pedantic -Wno-long-long -Wno-variadic-macros -Werror=uninitialized -DDO_HOST_BY_NAME -L. xbe_root.o ast_attribute.o xbe_interface.o xbe_structure.o xbe_argument.o xbe_field.o ast_union.o utl_error.o xbe_source.o xbe_argument2.o utl_pragmas.o ast_union_label.o cppgen.o xbe_attribute.o ast_typedef.o xbe_init.o fe_init.o ast_value_fwd.o y_tab.o ast_concrete_type.o utl_indenter.o ast_type.o drv_init.o xbe_predefined.o ast_exception.o ast_generator.o fe_private.o xbe_args.o ast_recursive.o ast_constant.o utl_decllist.o std.o lex_yy.o xbe_incl.o utl_identifier.o drv_fork.o drv_args.o xbe_type.o utl_wstring.o xbe_exception.o xbe_generator.o ast_decl.o drv_param.o xbe_constant.o ast_field.o fe_value_header.o utl_idlist.o xbe_globals.o xbe_cppscope.o ast_union_branch.o ast_initializer.o utl_strlist.o utl_stack.o xbe_cppname.o fe_declarator.o nr_narrow.o xbe_interface2.o xbe_cppfwd.o ast_check.o fe_interface_header.o ast_root.o ast_interface_fwd.o ast_expression.o utl_scope.o xbe_direction.o utl_list.o utl_string.o xbe_string.o utl_namelist.o xbe_module.o ast_redef.o ast_operation.o fe_extern.o ast_string.o xbe_dispatchable.o ast_enum.o utl_exceptlist.o ast_enum_val.o ast_module.o ast_array.o xbe_cpptype.o ast_predefined_type.o xbe_genlist.o xbe_classes.o xbe_operation.o utl_global.o utl_exprlist.o drv_link.o xbe_union.o xbe_array.o drv_preproc.o xps_vector.o ast_opaque.o xbe_literals.o ast_sequence.o ast_value.o xbe_classgen.o xbe_utils.o xbe_invoke.o fe_value_inheritance_spec.o xbe_hash.o xps_string.o utl_labellist.o xbe_interface3.o xbe_dispatcher.o xbe_value.o drv_private.o drv_main.o xbe_codegen.o ast_statemember.o xbe_expr_val.o xbe_opnameset.o xbe_produce.o ast_interface.o ast_structure.o xbe_time.o ast_argument.o xbe_arglist.o ast_hdrs.o xbe_enum.o xbe_sequence.o ast_boxed_value.o xbe_typedef.o libstdc++.a -lc -lm -ldl -lpthread -lrt -lddscpp -lddshts -o cppgen g++: error: libstdc++.a: Too many levels of symbolic links make[5]: *** [cppgen] Error 1I found that the symbolic link to libstdc++.a was pointing to the wrong spot:
$ cd src/tools/cppgen/bld/x86_64.linux-release/ $ ls -l libstdc++.a lrwxrwxrwx. 1 cornell games 11 Mar 11 10:54 libstdc++.a -> libstdc++.a
I manually ran the output of the command, as found in the makefile found in cppgen:
$ g++ -m64 -print-file-name=libstdc++.a libstdc++.a
Some more digging and it seems that I don't have libstdc++.a installed on the system, as this is not part of the standard g++ packages. I found this bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1201970
So all I had to do to resolve this issue is install the "libstdc++-static" RPM.
Bottom Line: the development documentation needs to be updated describing that you will be performing static linking of libstdc++ OR your feature testing in the configure script should look for libstdc++.a.
Note: I think that the 'g++ -m64 -print-file-name=libstdc++.a' command to print out the name of the file without a path is a bug on g++.