problems generating exe file

[Eder Urruela]

Hello!

I have started many threads about problems compiling an old code made for PA-RISC in integrity, I think finally I have solve all the problems ralated with computer architecture, but now I have the following problems, when I link the libraries I have generated in order to make the final exe.

../../lib/libZtddServ.a ../../lib/libZt.a \
/obras/master/IHM/VI/lib/libcgInterface.a \
../../lib/libXwnlio.a ../../lib/libXw.a ../../lib/libXtR2.a -lX1
1 -lm
ld: Unsatisfied symbol "IS_FCN_PTR" in file ../../lib/libZt.a[callback.o]
ld: Unsatisfied symbol "XtStrings" in file ../../lib/libZtddServ.a
ld: Unsatisfied symbol "IS_INT8_PTR" in file ../../lib/libZt.a[prm.o]
ld: Unsatisfied symbol "IS_UINT16_PTR" in file ../../lib/libZt.a[color.o]
ld: Unsatisfied symbol "__1kanji" in file ../../lib/libIVIbuild.a[liberror.o]
ld: Unsatisfied symbol "XtWindowOfObject" in file ../../lib/libZtddServ.a
ld: Unsatisfied symbol "IS_REAL64_PTR" in file ../../lib/libZt.a[filledge.o]
ld: Unsatisfied symbol "XtShellStrings" in file ../../lib/libZtddServ.a
ld: Unsatisfied symbol "IS_STRUCT_PTR" in file ../../lib/libZt.a[callback.o]
ld: Unsatisfied symbol "IS_INT32_PTR" in file ../../lib/libZt.a[callback.o]
10 errors.
*** Error exit code 1

I don't undertand why I have this problems because all these "Unsatisfied symbols" are defined in the .c and .h file which I used to compile the libraries.

Thanks!

[Dennis Handly · Accepted solution]

>all these "Unsatisfied symbols" are defined in the .c and .h file which I used to compile the libraries.

Are they in your libs?
nm -pxAN ../../lib/lib* | grep -e S_FCN_PTR -e IS_UINT16_PTR

Do you have the archive libs in the right order? (You can use -Wl,+n to keep searching.)

[Eder Urruela]

>Are they in your libs?

Yes they are in my libraries, all o them.
But I have discovered that the symbols like IS_FCN_PTR, IS_INT8_PTR and these, aren't defined, because I haven't inlcude one the hp9000s800, one define which is related with the arquitecture but it seems to be necesary not for the compilation, but yes for the linking.
I can remake the library libZt.a, but I don't where is defined the XtStrings and all the symbols related with. I have found one declaration in StringDef.h
extern _XtStringDefs_h_Const char XtStrings[];
but i don't know.

Thanks again!

[Eder Urruela]

Adding the -D9000s800 in the Makefiles of the library libZt.a I have got to solve most of the error I had.

The ones I have now are the following:

cc -L /usr/lib/X11R6 -o ../../bin/ivibuild ivibuild.o cgPonerBPR.o ../../lib/libIVIbuild.a \
../../lib/libZtddServ.a ../../lib/libZt.a \
/obras/master/IHM/VI/lib/libcgInterface.a \
../../lib/libXwnlio.a ../../lib/libXw.a ../../lib/libXtR2.a -lX11 -lm
ld: Unsatisfied symbol "XtStrings" in file ../../lib/libZtddServ.a
ld: Unsatisfied symbol "__1kanji" in file ../../lib/libIVIbuild.a[liberror.o]
ld: Unsatisfied symbol "XtWindowOfObject" in file ../../lib/libZtddServ.a
ld: Unsatisfied symbol "XtShellStrings" in file ../../lib/libZtddServ.a
4 errors.
*** Error exit code 1

Stop.

I supose I could solve these problems adding one define to the obslote Makefile, but I don't Know where I should look for it.
I Know the Xt[somthing) are related with the graffics programming.

Thanks again!

[Dennis Handly]

Adding -D9000s800 is probably wrong since you aren't on a PA-RISC (9000) machine.

__1kanji seems to only appear in PA libc. This was probably obsoleted long ago. Where are you referencing this symbol?

Using that "nm -pxAN", you can search system directories. XtShellStrings is defined in /usr/lib/hpux32/libXt.so, -lXt.

[Eder Urruela]

>Adding -D9000s800 is probably wrong since you aren't on a PA-RISC (9000) machine

I Know that it isn't the ideal option but I have ten following code in one include whisch is asked in many source files:

#ifdef hp9000s800
#define REV_STACK 1

#define IS_INT8_PTR(addr) (TRUE)
#define IS_UINT8_PTR(addr) (TRUE)

#define IS_INT16_PTR(addr) (((unsigned)addr & 0x00000001) == 0)
#define IS_UINT16_PTR(addr) (((unsigned)addr & 0x00000001) == 0)

#define IS_INT32_PTR(addr) (((unsigned)addr & 0x00000003) == 0)
#define IS_UINT32_PTR(addr) (((unsigned)addr & 0x00000003) == 0)
#define IS_REAL32_PTR(addr) (((unsigned)addr & 0x00000003) == 0)
#define IS_PTR_PTR(addr) (((unsigned)addr & 0x00000003) == 0)
#define IS_FCN_PTR(addr) (((unsigned)addr & 0x00000001) == 0)
/* On the 800, structures are either 2, 4 or 8 byte aligned depending on
* their contents. The following checks for 4 byte aligned because all of
* our structures start with a 4 byte aligned element. If this is used for
* any other structures, something will have to happen.
*/
#define IS_STRUCT_PTR(addr) (((unsigned)addr & 0x00000003) == 0)

#define IS_REAL64_PTR(addr) (((unsigned)addr & 0x00000007) == 0)
#endif hp9000s800

this file is calles host.h and It doesn't have defines for modern architectures and it necesary for the compilation

__1kanji seems to only appear in PA libc. This was probably obsoleted long ago. Where are you referencing this symbol?


This defines is a mistery by the moment.

And usig the nm -pxAN command I have found where the Xt elements are an I have discovered that the Makefile gives the old libraries to the cc which haven't have defined the XtStrings XtWindowOfObject an the XtShellStrings, so I have change them for the new libraries an now appears new compilation errors.

That's a conviction...

Thanks for your ideas.

[Dennis Handly]

>#define REV_STACK 1

Did you change this to a 1 for IPF?

These are all bogus and aren't valid for 64 bit:
==========================================================
#define IS_INT16_PTR(addr) (((unsigned long)addr & (sizeof(short) -1UL)) == 0)
#define IS_UINT16_PTR(addr) (((unsigned long)addr & (sizeof(unsigned short) -1UL)) == 0)

#define IS_INT32_PTR(addr) (((unsigned long)addr & (sizeof(int) -1UL)) == 0)
#define IS_UINT32_PTR(addr) (((unsigned long)addr & (sizeof(unsigned int) -1UL)) == 0)
#define IS_REAL32_PTR(addr) (((unsigned long)addr & (sizeof(float) -1UL)) == 0)
#define IS_PTR_PTR(addr) (((unsigned long)addr & (sizeof(void*) -1UL)) == 0)
#define IS_FCN_PTR(addr) (((unsigned long)addr & (sizeof(long long) -1UL)) == 0)
#define IS_STRUCT_PTR(addr) (((unsigned long)addr & (sizeof(int) -1UL)) == 0)
#define IS_REAL64_PTR(addr) (((unsigned long)addr & (sizeof(double) -1UL)) == 0)

>This defines is a mystery by the moment.

Just grep your sources and includes for __1kanji.

>now appears new compilation errors.

Which are?

[Eder Urruela]

>>#define REV_STACK 1

>Did you change this to a 1 for IPF?

No I haven't done any change, all this code is the original source.

>These are all bogus and aren't valid for 64 bit:

So I should change the defines I have for these ones.

>>now appears new compilation errors.

>Which are?
The mistakes are related with the change of the libraris, now are requires new #includes, because the Makefile gave to the compiler a path with the old libraries.
I have found this libraries in /usr/include/X11 | /usr/include/Xm | /usr/include/Xw directories.
I'm adding this paths, and replacing old libraries with the new ones, but there are somo old libraries which I think are neccesry.
I'm purging the compilation errors little by little, I don't post this list because is too long.
But I attach the last list

[Eder Urruela]

One of the more frequent error are related with te declaration of the fuction which seem to havo less parameter than the old ones.

"Cascade.c", line 397: error #2140: too many arguments in function call
menubutton_class.idealWidthProc))(menuButton, &idealWidth);
^

"Cascade.c", line 823: error #2140: too many arguments in function call
paneManagedChildren) (grandparent, mw);
^

I suposse the parameter which now aren't necesary should be removed, but I'm worried about other problems could apear from those, the idealWidth may be use for control something that now could be controlled by other function, or something similar.

I think that actualizing the *.h files it's a bit "dangerous"

Thanks again!

[Dennis Handly]

>No I haven't done any change, all this code is the original source.

Then you should set it to 0:
#define REV_STACK 0
Or remove the definition. The stack on IPF grows in reverse, the opposite of PA.

>So I should change the defines I have for these ones.

Most of the values are the same except for IS_FCN_PTR & IS_PTR_PTR.

>One of the more frequent error are related with the declaration of the function which seem to have less parameter than the old ones.

Hmm, I guess this new version is very different.

[Eder Urruela]

Yes the new version is very diferent, for example two new error are refered to system fuctions whose declaration is the following typedef void (*XtWidgetProc)(Widget) and typedef void (*XtProc)(void).

I can see that actually have only one parameter, but in the source file I am compiling are called with two parameters and the error is that the function has too many parameter. So I think I should remove the parameter which do not fix with the declaration.

I supose it is going to afect to the program working, but not how.

Any recomendations?

Thanks!

[Dennis Handly]

>I think I should remove the parameter which do not fix with the declaration.

Yes.

>I suppose it is going to affect to the program working, ... Any recommendations?

If you had old and new man pages, you could compare. Otherwise you'll have to look at the new man page and basically start over with the call.

[Eder Urruela]

I haven't the old man pages, but I'm going to make a backup and try.

Thank you very much Dennis.

[Eder Urruela]

I have make the guess, but I have not sucess, I changed the header files which call to the Xt functions, but I continue with the same problem.

ld: Unsatisfied symbol "XtStrings" in file ../../lib/libZtddServ.a
ld: Unsatisfied symbol "__1kanji" in file ../../lib/libIVIbuild.a[liberror.o]
ld: Unsatisfied symbol "XtWindowOfObject" in file ../../lib/libZtddServ.a
ld: Unsatisfied symbol "XtShellStrings" in file ../../lib/libZtddServ.a

I have done a call to nm -pxAN lib* | grep -e XtStrings and I have found the following results.

0x00000000 U ../../lib/libXtR2.a[Core.o]:XtStrings
0x00000000 U ../../lib/libXtR2.a[Event.o]:XtStrings
0x00000000 U ../../lib/libXtR2.a[Intrinsic.o]:XtStrings
0x00000000 U ../../lib/libXtR2.a[Popup.o]:XtStrings
0x00000000 U ../../lib/libXtR2.a[Resources.o]:XtStrings
0x00000000 U ../../lib/libXtR2.a[Shell.o]:XtStrings
0x00000000 U ../../lib/libXtR2.a[TMparse.o]:XtStrings
0x00000000 U ../../lib/libXtR2.a[TMstate.o]:XtStrings
0x00000000 U ../../lib/libXw.a[Arrow.o]:XtStrings
0x00000000 U ../../lib/libXw.a[Button.o]:XtStrings
0x00000000 U ../../lib/libXw.a[Cascade.o]:XtStrings
0x00000000 U ../../lib/libXw.a[Display.o]:XtStrings
0x00000000 U ../../lib/libXw.a[Form.o]:XtStrings
0x00000000 U ../../lib/libXw.a[ImageEdit.o]:XtStrings
0x00000000 U ../../lib/libXw.a[List.o]:XtStrings
0x00000000 U ../../lib/libXw.a[ListRC.o]:XtStrings
0x00000000 U ../../lib/libXw.a[Manager.o]:XtStrings
0x00000000 U ../../lib/libXw.a[MenuBtn.o]:XtStrings
0x00000000 U ../../lib/libXw.a[MenuMgr.o]:XtStrings
0x00000000 U ../../lib/libXw.a[MenuPane.o]:XtStrings
0x00000000 U ../../lib/libXw.a[MenuSep.o]:XtStrings
0x00000000 U ../../lib/libXw.a[PButton.o]:XtStrings
0x00000000 U ../../lib/libXw.a[Panel.o]:XtStrings
0x00000000 U ../../lib/libXw.a[PopupMgr.o]:XtStrings
0x00000000 U ../../lib/libXw.a[Primitive.o]:XtStrings
0x00000000 U ../../lib/libXw.a[Pulldown.o]:XtStrings
0x00000000 U ../../lib/libXw.a[RCManager.o]:XtStrings
0x00000000 U ../../lib/libXw.a[ResConvert.o]:XtStrings
0x00000000 U ../../lib/libXw.a[SRaster.o]:XtStrings
0x00000000 U ../../lib/libXw.a[SText.o]:XtStrings
0x00000000 U ../../lib/libXw.a[SWindow.o]:XtStrings
0x00000000 U ../../lib/libXw.a[Sash.o]:XtStrings
0x00000000 U ../../lib/libXw.a[ScrollBar.o]:XtStrings
0x00000000 U ../../lib/libXw.a[SourceDsk.o]:XtStrings
0x00000000 U ../../lib/libXw.a[SourceStr.o]:XtStrings
0x00000000 U ../../lib/libXw.a[TextEdit.o]:XtStrings
0x00000000 U ../../lib/libXw.a[TitleBar.o]:XtStrings
0x00000000 U ../../lib/libXw.a[Toggle.o]:XtStrings
0x00000000 U ../../lib/libXw.a[VPW.o]:XtStrings
0x00000000 U ../../lib/libXw.a[Valuator.o]:XtStrings
0x00000000 U ../../lib/libXw.a[WorkSpace.o]:XtStrings
0x00000000 U ../../lib/libXwnlio.a[SourceDsk.o]:XtStrings
0x00000000 U ../../lib/libXwnlio.a[Display.o]:XtStrings
0x00000000 U ../../lib/libXwnlio.a[SourceStr.o]:XtStrings
0x00000000 U ../../lib/libXwnlio.a[TextEdit.o]:XtStrings
0x00000000 U ../../lib/libZtddServ.a:XtStrings

XtStrings apperas in all the libaries which I have linked, so, the problem could be in the Makefile?

Thanks!

[Dennis Handly]

>but I continue with the same problem.
ld: Unsatisfied symbol "__1kanji" in liberror.o

Compile this file with "-E -.i" and look at liberror.i. Search for __1kanji. This symbol is obsolete and isn't valid for any 11.x system. You must have some 10x headers with this bad macro?

>I have done a call to nm -pxAN lib* | grep -e XtStrings and I have found the following results.

Did you look in /usr/lib/hpux32/lib*?

>XtStrings appears in all the libraries which I have linked
U ../../lib/libXtR2.a[Core.o]:XtStrings

The "U" stands for unsats, there are no definitions here.

>the problem could be in the Makefile?

Only if the Makefile forgot to add some -lXX.
Is there a man entry for XtStrings?

[Eder Urruela]

>Compile this file with "-E -.i" and look at liberror.i. Search for __1kanji. This symbol is obsolete and isn't valid for any 11.x system. You must have some 10x headers with this bad macro?

I have problems to generate a preprocessed file, but I can confirm that this program was made under the 9x versión of HP-UX.

Did you look in /usr/lib/hpux32/lib*?

I don't use any liebary from this folder.


>The "U" stands for unsats, there are no definitions here.

Ok I see now, I suposse the linker only shows me te first undefinition it finds.

>Only if the Makefile forgot to add some -lXX.

I think all the necesary -I paths are included in the makefile.

Is there a man entry for XtStrings?

There is not any man entry for XtStrings, but the are one for XtWindowOfObject.

Thanks!

[Eder Urruela]

The only file where I have references to XtStrings, is in the header file StringDefs.h

extern _XtStringDefs_h_Const char XtStrings[];

in that line, in the following lines XtStrings are used like this:

#ifndef XtNaccelerators
#define XtNaccelerators ((char*)&XtStrings[0])
#endif
#ifndef XtNallowHoriz
#define XtNallowHoriz ((char*)&XtStrings[13])
...

I have the extern, but I think I need something some.

Thanks!

[Dennis Handly]

>I have problems to generate a preprocessed file

Why? What errors?

>I can confirm that this program was made under the 9.x version of HP-UX.

That would explain __1kanji.

>>Did you look in /usr/lib/hpux32/lib*?

>I don't use any library from this folder.

If you are on Integrity, you must use some libs from here or hpux64/.

>I suppose the linker only shows me the first unsat it finds.

It should show all.

>>Only if the Makefile forgot to add some -lXX.

>I think all the necessary -I paths are included in the makefile.

That's -l. And probably -lXt from below.

>The only file where I have references to XtStrings, is in the header file StringDefs.h
extern _XtStringDefs_h_Const char XtStrings[];

This is defined in:
/usr/lib/libXt.1: D XtStrings
/usr/lib/libXt.2: D XtStrings
/usr/lib/libXt.3: D XtStrings

Or:
D /usr/lib/hpux32/libXt.so.1:XtStrings

[Eder Urruela]

>>I have problems to generate a preprocessed file

>Why? What errors?

The cc command returns me the preproccesed file into the screen, not into a *.i file. Despite I give a liberror.i into the command line.


>>>Did you look in /usr/lib/hpux32/lib*?

>>I don't use any library from this folder.


I am no using this folder and after your explanation I am thiking that it could be the problem, I don't have compilation error, and I make my libraries from the source files I have, without any reference to the a lib folder.

>>>Only if the Makefile forgot to add some -lXX.

>>I think all the necessary -I paths are included in the makefile.

>That's -l. And probably -lXt from below.

These are my flags in the makefile I compile the source files which I use to generate the libIVIbuild.a

CCFLAGS = -Wp,-H564000 -DRELEASE -D_IVIOVISUAL -D_INCLUDE_HPUX_SOURCE -D_INCLIDE
_POSIX_SOURCE -D_HPUX_SOURCE -D_CLASSIC_TYPES -DX11R6 -I/hpivi/tape/usr/include/
X11R2 -I/usr/include/X11R6 -I/usr/rtap/include -I/obras/master/EC/include -I/usr
/old/usr/include.

And This my call to the linker in order to generate the final exe file. Ivibuild

$(BIN)/ivibuild: ivibuild.o cgPonerBPR.o $(OBJLIB)
$(LINK) -o $(BIN)/ivibuild ivibuild.o cgPonerBPR.o $(OBJLIB) \
$(LIB)/libZtddServ.a $(LIB)/libZt.a \
$(CG_DIR_IHM_VI)/lib/libcgInterface.a \
$(LIB)/libXwnlio.a $(LIB)/libXw.a $(LIB)/libXtR2.a -lX11 -lm

I am thinking abuot add the libXt.1, libXt.2, libXt.3 to the las command line in order to include the symbols which now are undefined.


>This is defined in:
>/usr/lib/libXt.1: D XtStrings
>/usr/lib/libXt.2: D XtStrings
>/usr/lib/libXt.3: D XtStrings

>Or:
>D /usr/lib/hpux32/libXt.so.1:XtStrings

That is a very good clue, thaks you very much.

[Eder Urruela]

When I had the -l /usr/lib/libXt.1 the linker returns a:
ld: Mismatched ABI (not an ELF file) for /usr/lib/libXt.1
Fatal error.

what can I do?

Thanks!

[Eder Urruela]

Finally I have solved the XtStrings, XtWindowOfObject an XtshellStrings problesms,
adding in the makefile the libXt.so.1 of the folder /usr/lib/hp32 as Dennis said.

Now I have the only problem of the obsolete __1kanji symbol.

I have discobered that in the version 9.X it was in the system library libc.so but now in the version 11.31 it does not appear.

Finally I have also got a prepocessed file but __1kanji did not apperar in liberror.i.

I think I have two alternatives, remove the __1kanji from the source, if (it would appear) or search the old library libc.so from the hpux 9.x and give it to the linker.

Any ideas? Thaks!

[Dennis Handly]

>adding in the makefile the libXt.so.1 of the folder /usr/lib/hp32 as Dennis said.

I hope you used just -lXt.

>Now I have the only problem of the obsolete __1kanji symbol.
>I have discovered that in the version 9.X it was in the system library libc.so but now in the version 11.31 it does not appear.

Didn't I say that? It also isn't in 11.23 either.

>I have also got a preprocessed file but __1kanji did not appear in liberror.i.

If you see __1kanji in the nm output for liberror.o, it should be in the .i file too.

>I think I have two alternatives, remove the __1kanji from the source,

This is your only choice.

>search the old library libc.so from the hp-ux 9.x and give it to the linker.

There is no Integrity libc.so from 9.x, since that was almost a decade before Integrity was released.

[Eder Urruela]

Finally I get a new compiled version.

__1kanji was used under another function in the sources as FIRSTof2, it was use to addapt 16 bit variables. I have removed it from the sources, expecting not to causes too many problems.

So Thank you everybody, expecially to Dennis whom a will not give to his answer more than 10 pints because i can't.

Thank you again.

[Dennis Handly]

>__1kanji was used under another function in the sources as FIRSTof2, it was use to adapt 16 bit variables.

This is used to check if a multibyte char. The correct way to check is to use mblen(3) to see how long each char sequence is.

[Eder Urruela]

>This is used to check if a multibyte char. The correct way to check is to use mblen(3) to see how long each char sequence is.

Thaks! it's an important point.

Now I'm going to work in the debug of the program and I'm sure this point will be very neccesary, because as I expected it does't work properly and returns API error messages.
I'm studing the manuals in order to identify the problems.

Surely I'll be back soon with new doubts about this. But I think it should be on a new thread.

Thanks again.