1827514
Members
2809
Online
109965
Solutions
SOLVED
i dont think this has anything to do with PHSS_28871 (a linker/loader patch) because the build did not even reach the link stage, and no linker/loader/related include files are involved.
the problem is that gcc supplies its own sys/types.h which does not define the type sbsize_t, which is defined in HP-supplied /usr/include/sys/types.h. so you may consider adding this piece to gcc-supplied
sys/types.h .
# ifndef _BSIZE_T
# define _BSIZE_T
# if defined(_APP32_64BIT_OFF_T) || defined(_KERNEL)
typedef int64_t sbsize_t; /* signed length in bytes */
typedef uint64_t bsize_t; /* unsigned length in bytes */
# else
typedef long sbsize_t;
typedef unsigned long bsize_t;
# endif
# endif /* _BSIZE_T */
or, include /usr/include/sys/types.h instead of the gcc-supplied one (not sure if that will work well in all respects).
--
ranga
[i work for hpe]
the problem is that gcc supplies its own sys/types.h which does not define the type sbsize_t, which is defined in HP-supplied /usr/include/sys/types.h. so you may consider adding this piece to gcc-supplied
sys/types.h .
# ifndef _BSIZE_T
# define _BSIZE_T
# if defined(_APP32_64BIT_OFF_T) || defined(_KERNEL)
typedef int64_t sbsize_t; /* signed length in bytes */
typedef uint64_t bsize_t; /* unsigned length in bytes */
# else
typedef long sbsize_t;
typedef unsigned long bsize_t;
# endif
# endif /* _BSIZE_T */
or, include /usr/include/sys/types.h instead of the gcc-supplied one (not sure if that will work well in all respects).
--
ranga
[i work for hpe]
you should not be modifying /usr/include/sys/types.h - this file is fine as it is.
i meant the gcc-supplied types.h which will be in some location like
/usr/local/lib/gcc-lib/hppa2.0n-hp-hpux11.00/3.2/include/sys/types.h
this is the file that gets included when you compile with gcc because gcc's default include path has the above path first and /usr/include later.
--
ranga
[i work for hpe]
i meant the gcc-supplied types.h which will be in some location like
/usr/local/lib/gcc-lib/hppa2.0n-hp-hpux11.00/3.2/include/sys/types.h
this is the file that gets included when you compile with gcc because gcc's default include path has the above path first and /usr/include later.
--
ranga
[i work for hpe]
the problem is because of the following line in the makefile:
CFLAGS = -g -w -I/opt/OV/include -I. $(SNMP_LIBPATH) /opt/OV/lib
you want to include the library lookup path but you missed the -L.
you should change that to
CFLAGS = -g -w -I/opt/OV/include -I. -L $(SNMP_LIBPATH) -L/opt/OV/lib
note that the makefile is not initializing SNMP_LIBPATH. you have to correct that.
--
ranga
[i work for hpe]
CFLAGS = -g -w -I/opt/OV/include -I. $(SNMP_LIBPATH) /opt/OV/lib
you want to include the library lookup path but you missed the -L.
you should change that to
CFLAGS = -g -w -I/opt/OV/include -I. -L $(SNMP_LIBPATH) -L/opt/OV/lib
note that the makefile is not initializing SNMP_LIBPATH. you have to correct that.
--
ranga
[i work for hpe]
/usr/ccs/bin/ld: /opt/OV/lib: Not a valid object file (invalid system id)
this is because the link line had /opt/OV/lib as an input file to ld. it should have followed a '-L'. this has nothing to do with 32/64 bit. header file problems cannot be solved by changing from 32-bit to 64-bit.
as for unresolved symbols, i think compiling and linking with aCC (instead of gcc) may resolve the problem.
--
ranga
[i work for hpe]
this is because the link line had /opt/OV/lib as an input file to ld. it should have followed a '-L'. this has nothing to do with 32/64 bit. header file problems cannot be solved by changing from 32-bit to 64-bit.
as for unresolved symbols, i think compiling and linking with aCC (instead of gcc) may resolve the problem.
--
ranga
[i work for hpe]
here is the reason why the unresolved symbols appear: libraries libstd.2, libov.3 and libsnmp.3 are built with aCC. so they have references to symbols defined in libCsup.sl.
now you did not compile/link with aCC so your program does not link with libCsup.sl. hence the unresolved symbols.
there are a few ways to resolve this:
1. build your application with aCC so that libCsup is included in the link line by the compiler. all other related problems are also avoided.
2. link your application with libCsup by adding the following to CFLAGS: -lCsup
3. use LD_PRELOAD to preload libCsup at run-time. you can do this with the command
LD_PRELOAD=/usr/lib/libCsup.sl ./AlcPabxPolling
compiling and linking for PA64 instead of PA32 may solve your problem in some mysterious way but you may not be able to do it all the time.
--
ranga
[i work for hpe]
now you did not compile/link with aCC so your program does not link with libCsup.sl. hence the unresolved symbols.
there are a few ways to resolve this:
1. build your application with aCC so that libCsup is included in the link line by the compiler. all other related problems are also avoided.
2. link your application with libCsup by adding the following to CFLAGS: -lCsup
3. use LD_PRELOAD to preload libCsup at run-time. you can do this with the command
LD_PRELOAD=/usr/lib/libCsup.sl ./AlcPabxPolling
compiling and linking for PA64 instead of PA32 may solve your problem in some mysterious way but you may not be able to do it all the time.
--
ranga
[i work for hpe]
to make it simple - because of the unresolved symbols problem i recommend that you use aCC.
if you prefer gcc, perhaps you should try compiling it with the correct version as others have suggested. if the problem of unresolved symbols is still not solved, i think using aCC is the solution.
--
ranga
[i work for hpe]
if you prefer gcc, perhaps you should try compiling it with the correct version as others have suggested. if the problem of unresolved symbols is still not solved, i think using aCC is the solution.
--
ranga
[i work for hpe]