GCC 4.4.5 not understanding -blibpath when compiling ADL

[houchin]

Hi all,

We'll, I had ADL installed on a couple systems, but I'm finding it a lot fussier than ADL 3. One error that has come up is the following, when trying to use the parallel make file is that it doesn't like the -blibpath option:

Code: Select all

Creating size validation script
/apps/gcc-4.4.5/bin/g++ -DBYTE_ORDER_LE -DADL_ENV -D_USE_FLAT_FILE_ -D_THREAD_SAFE -DGCC -m64 -fPIC -Wall -Wno-unknown-pragmas     -DEXCLUDE_CRIS -O3 -m64 -Xlinker -zmuldefs -blibpath:/usr/lib:/lib -o ProCmnValidateViirsDictionarySize.exe ProCmnValidateViirsDictionarySize.o   -L/apps/user/aero/adl/adl4/common/local/lib -lhdf5 -lz                  -L/usr/lib -lm -lc -lrt -lpthread -lgfortran                  -L/apps/user/aero/adl/adl4/common/local/lib -llog4cplus                  -L/apps/user/aero/adl/adl4/ADL/lib -lProCmnIPO -lProCmnUtil                  -lProCmnDictionary -lProCmnDictEntries                  -lProCmnStrings                  -lInfUtil_Cfg  -lInfUtil_Perf -lInfTk -lInfCmnUtil -lInfCmnExc                  -lInfUtil_Dbg -lInfUtil_Tim -lInfUtilGran                  -lDmCoreDb                  -lDmApi                  -lDmCoreLibrary                  -lDmImInventory                  -lDmImInventoryAdaptation                  -lDmMgmt                  -lDmSmStorage                  -lDmSmStorageAdaptation                  -lADLPacker -lADLHDF -lADLUtil                  -L/apps/user/aero/adl/adl4/common/local/lib -lboost_filesystem                  -L/apps/user/aero/adl/adl4/common/local/lib -lxerces-c                  -lProCmnMath                  -L/apps/user/aero/adl/adl4/common/local/lib -lpppack -L/apps/user/aero/adl/adl4/ADL/lib -lProCmnValidateDictionarySize    -lProCmnDictionary      -lProCmnDictEntries     -lProCmnAncDictEntries      -lProCmnViirsDictEntries    -lProCmnViirsVerifiedRDRDictEntries     -lProCmnMode    -lProSdrCmnGeo      -lProCmnGeoloc      -lnovasc    -lProCmnMath          -lProGipViirsTileInterfaces   -L/apps/user/aero/adl/adl4/common/local/lib -lboost_regex
g++: unrecognized option '-blibpath:/usr/lib:/lib'

I did some looking in the GCC website, and this does appear to be a valid option and it does appear to be formatted correctly.
When I use the single-threaded buildAdl.ksh script, I can find no mention of -blibpath in any of the Makefiles.

Any ideas on what's happening?

[houchin]

Ok, I did some digging, and I think this is a bug that snuck through. -blibpath is an option for the AIX linker, but not Linux. In ADL/imakeconf/PRO_Config, I am thinking that the debug section really should be:

Code: Select all

#ifdef Debug

#ifdef XL
#define Debug_Optn -g -qcheck -qflttrap -qfullpath
OPTIMIZE_OPT =
#define Loader_Libpath
#endif

#if defined(GCC) || defined(CYG_GCC) || defined(ADL_MINGW_GCC)
#define Debug_Optn -ggdb3
OPTIMIZE_OPT =
#define Loader_Libpath
#endif

#else

#define Debug_Optn
#if defined(GCC) || defined(CYG_GCC) || defined(ADL_MINGW_GCC)
#define Loader_Libpath -L/usr/lib -L/lib
#else
#define Loader_Libpath -blibpath:/usr/lib:/lib
#endif

#endif

Or alternately should it really just be left empty? On Linux, do we really need to tell it to look in the standard places?

[kbisanz]

You're correct that -blibpath is an AIX linker thing that snuck through. It doesn't cause a hard error, so that's how it was missed.

I corrected the PRO_Config file using your suggested change. Since this isn't a hard error, I don't think it warrants a patch just for this, but it'll get sent out in the next patch.

[houchin]

If you can verify that fix on your end, that would be great. I have since set to to blank for GCC on Linux, as I was having other issues. /usr/lib is listed in the LIBRARIES variable for GCC and I expect that /lib isn't needed, and might even be wrong (i.e., is it really wanting /lib64?).

[kbisanz]

Your suggestion regarding Loader_Libpath worked for me.

The 64 bit libraries needed are very likely in /lib64 and /usr/lib64 instead of /lib and /usr/lib. However, I am not sure if that's always the case or not across different Linux distros. You're correct that /lib64 and /usr/lib64 are already part of GCC's default search path. On our system (RHEL 5.4, GCC 4.4.0) using the -v option to GCC shows:

Code: Select all

LIBRARY_PATH=/usr/lib/gcc/x86_64-redhat-linux6E/4.4.0/:/usr/lib/gcc/x86_64-redhat-linux6E/4.4.0/:/usr/lib/gcc/x86_64-redhat-linux6E/4.4.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux6E/4.4.0/../../../:/lib/:/usr/lib/

Having both /lib and /lib64 available isn't a problem. The linker should figure out which one it needs. That's the source of the "skipping incompatible" warnings from ld, such as:

Code: Select all

/usr/bin/ld: skipping incompatible /usr/lib/librt.so when searching for -lrt
/usr/bin/ld: skipping incompatible /usr/lib/librt.a when searching for -lrt
/usr/bin/ld: skipping incompatible /usr/lib/libpthread.so when searching for -lpthread
/usr/bin/ld: skipping incompatible /usr/lib/libpthread.a when searching for -lpthread
/usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc

The above "warnings" are more informational and don't indicate a problem unless you're actually having linking errors and believe you should be linking with one of the ones it says is incompatible.