Operating System - Linux
1753516 Members
5323 Online
108795 Solutions
New Discussion юеВ

Re: Using aCC 06.15 compiler veersion => Identifier "__fpreg" is undefined

 
SOLVED
Go to solution
Neel2
Regular Advisor

Re: Using aCC 06.15 compiler veersion => Identifier "__fpreg" is undefined

Thanks for your reply.

Ohh, that means do i need to modify the existing source code in order to get compile/link error free with aCC6. The similar source code was working fine ( compile/linking) w/o any error, So aCC6 strict enough to find wrong typedefs now, when it was not able to find earlier(compare with aCC3.57).

We are porting our source code, from aCC3.57 to aCC6.15.

Best regards,
Neel
Neel2
Regular Advisor

Re: Using aCC 06.15 compiler veersion => Identifier "__fpreg" is undefined

Now, when i link with -Wf,-o for the following error:

ld: Unsatisfied symbol "ut_arg_strcmp(char*,char*,long)[_Z13ut_arg_strcmpPcS_l]" in file /disk/BUILD/aCC_6.15_build/lib/liboscfe.
a[utlog.o]

It shows the following output with nm:

$/usr/ccs/bin/nm -oA * | grep _Z13ut_arg_strcmpPcS_l
[111] |0000000000000|0000000000|FUNC |GLOB |0| UNDEF|libut.a[utlog.o]:_Z13ut_arg_strcmpPcS_l
[316] |0000000000000|0000000400|FUNC |GLOB |0| .text|libut.a[ut.o]:_Z13ut_arg_strcmpPcS_l
[69] |0000000000000|0000000000|FUNC |GLOB |0| UNDEF|libut.a[uttrcfmt.o]:_Z13ut_arg_strcmpPcS_l
[34] |0000000000000|0000000000|FUNC |GLOB |0| UNDEF|libut.a[utcrshpt.o]:_Z13ut_arg_strcmpPcS_l
[316] |0000000000000|0000000400|FUNC |GLOB |0| .text|ut.o:_Z13ut_arg_strcmpPcS_l
[34] |0000000000000|0000000000|FUNC |GLOB |0| UNDEF|utcrshpt.o:_Z13ut_arg_strcmpPcS_l
[111] |0000000000000|0000000000|FUNC |GLOB |0| UNDEF|utlog.o:_Z13ut_arg_strcmpPcS_l
[51] |0000000000000|0000000000|FUNC |GLOB |0| UNDEF|utstats.o:_Z13ut_arg_strcmpPcS_l
[69] |0000000000000|0000000000|FUNC |GLOB |0| UNDEF|uttrcfmt.o:_Z13ut_arg_strcmpPcS_l

//=======================================

Now, it does shows ".text" entry in [316] |0000000000000|0000000400|FUNC |GLOB |0| .text|libut.a [ut.o]:_Z13ut_arg_strcmpPcS_l
What does that mean? Is it defined?

Could you please let me know what should be my next step in order to find out the root cause of this linking error?

Best regards,
Neel
Dennis Handly
Acclaimed Contributor

Re: Using aC++ A.06.15 compiler version => Identifier "__fpreg" is undefined

>that means do I need to modify the existing source code in order to get compile/link error free with aCC6.

Possibly but strictly speaking, related to 11.23, not the compiler.

>The similar source code was working fine, So aCC6 strict enough to find wrong typedefs now, when it was not able to find earlier

No, it has nothing to do with the compiler. Mangling has always caught this. If anything, it is your OS headers that cause the difference.

>We are porting our source code, from aC++ A.03.57 to A.06.15.


And from 11.11 to 11.23.

Dennis Handly
Acclaimed Contributor

Re: Using aC++ A.06.15 compiler version => Identifier "__fpreg" is undefined

ld: Unsatisfied symbol ut_arg_strcmp(char*,char*,long)[_Z13ut_arg_strcmpPcS_l] liboscfe.a[utlog.o]
>It shows the following output with nm:
FUNC|GLOB|.text|libut.a[ut.o]:_Z13ut_arg_strcmpPcS_l

>What does that mean? Is it defined?

Yes.

>Could you please let me know what should be my next step in order to find out the root cause of this linking error?

Either you're not using -Wl,+n, you don't have -loscfe on the link line or you didn't regenerate all of the archives created by the foreign devil ar(1).

Neel2
Regular Advisor

Re: Using aCC 06.15 compiler veersion => Identifier "__fpreg" is undefined

Hi,

New observation: I stated OPTIMIZE build and now I am not getting those unstatisfied linking errors. what could be the reason behind it? will appreciate your quick reply.

Best regards,
Neel
Neel2
Regular Advisor

Re: Using aCC 06.15 compiler veersion => Identifier "__fpreg" is undefined

Hi,

Could you please let me know the following:

unsigned long function(vs_lock *lock)
{
unsigned long i, save;
unsigned int *ptr;

for (i = 0; i < VS_LOCK_SIZE; i++)
{
ptr = &lock->l_words[i];
if ((int) 0x0000000f & reinterpret_cast (ptr) )
continue;
else
{
lock->l_word = ptr;
save = i; /* in case i is undefined after the loop */
break;
}
}
*(lock->l_word) = 1;
return(save);
}


the above function got compiled for 32bit. but its giving an error (Invalide type definition for if ((int) 0x0000000f & reinterpret_cast (ptr) )
while compiling for 64bit.

So, what should be the equivalent of the above if statement for 64bit? Suggestions/pointers are always appreciated.

Best regards,
Nell
James R. Ferguson
Acclaimed Contributor

Re: Using aCC 06.15 compiler veersion => Identifier "__fpreg" is undefined

Dennis Handly
Acclaimed Contributor

Re: Using aC++ A.06.15 compiler version => Identifier "__fpreg" is undefined

>I started OPTIMIZE build and now I am not getting those unsatisfied linking errors. What could be the reason behind it?

The compiler and linker may delete the references as dead code.

>Could you please let me know the following:
unsigned int *ptr;
reinterpret_cast(ptr)
>the above function got compiled for 32bit. But it's giving an error (Invalid type definition reinterpret_cast(ptr)) while compiling for 64bit.

The Standard makes it illegal to cast a pointer to a smaller integral type.

>what should be the equivalent of the above if statement for 64bit?

You should be writing code that works for both 32 and 64 bit:
static_cast(reinterpret_cast(ptr))

Instead of long, you could be more pedantic and use ptrdiff_t. Or even more by using the C99 intptr_t.

You didn't mention you were porting to 64 bit in this thread.

>JRF: You might find this document quite helpful

Perhaps not since this is an error in all versions of aC++ and really is a 64 bit porting issue.

Neel2
Regular Advisor

Re: Using aCC 06.15 compiler veersion => Identifier "__fpreg" is undefined

Hello,
This error is linking error, which i posted in same thread(please have a look at previous thread)

Today i compare IPF linking result with PA (where all linking working properly),

PA output:

/usr/bin/nm -oA liboscfe.a | grep ut_arg_strcmp
liboscfe.a:ut_arg_strcmp__FPcT1l| |undef |code |
liboscfe.a:ut_arg_strcmp__FPcT1l|000000033730|extern|entry |$CODE$
liboscfe.a:ut_arg_strcmp__FPcT1l| |undef |code |
liboscfe.a:ut_arg_strcmp__FPcT1l| |undef |code |

IPF output:

$/usr/bin/nm -oA /disk/nkhemkar/VDS/aCC_6.15_build/kernel/7.0.1.4/HP-UX_32bit/dbg//lib/liboscfe.a | grep ut_arg_strcmp
[111] |0000000000000|0000000000|FUNC |GLOB |0| UNDEF|/disk/nkhemkar/VDS/aCC_6.15_build/kernel/7.0.1.4/HP-UX_32bit/dbg//lib/liboscfe.a[utlog.o]:_Z13ut_arg_strcmpPcS_l
[316] |0000000000000|0000000400|FUNC |GLOB |0| .text|/disk/nkhemkar/VDS/aCC_6.15_build/kernel/7.0.1.4/HP-UX_32bit/dbg//lib/liboscfe.a[ut.o]:_Z13ut_arg_strcmpPcS_l
[69] |0000000000000|0000000000|FUNC |GLOB |0| UNDEF|/disk/nkhemkar/VDS/aCC_6.15_build/kernel/7.0.1.4/HP-UX_32bit/dbg//lib/liboscfe.a[uttrcfmt.o]:_Z13ut_arg_strcmpPcS_l
[34] |0000000000000|0000000000|FUNC |GLOB |0| UNDEF|/disk/nkhemkar/VDS/aCC_6.15_build/kernel/7.0.1.4/HP-UX_32bit/dbg//lib/liboscfe.a[utcrshpt.o]:_Z13ut_arg_strcmpPcS_l
[316] |0000000000000|0000000400|FUNC |GLOB |0| .text|/disk/nkhemkar/VDS/aCC_6.15_build/kernel/7.0.1.4/HP-UX_32bit/dbg//lib/liboscfe.a[ut.o]:_Z13ut_arg_strcmpPcS_l



Remark: On PA where I can build and link sucessfully, the same souce code and linking order on IPF is giving the unsatisfied linking error. So, today i compare the above output of liboscfe.a and found that the same symbols on PA shows entry and extern.

liboscfe.a:ut_arg_strcmp__FPcT1l|000000033730|extern|entry |$CODE$


So, Could you please let me know why Its showing extern on PA and not on IPF.

Thanks in advance.
Regards,
Neel
Dennis Handly
Acclaimed Contributor

Re: Using aC++ A.06.15 compiler version => Identifier "__fpreg" is undefined

>This error is linking error, which I posted in same thread (please have a look at previous thread)

(It would have been better to reuse that other thread so I don't have to go back and forth.)

>PA output:

I see one definition and 3 uses.

>IPF output:

I see two definitions (extra copy?) and 3 uses.

>I compare the above output of liboscfe.a and found that the same symbols on PA shows entry and extern.
ut_arg_strcmp__FPcT1l|extern|entry |$CODE$

>Could you please let me know why it's showing extern on PA and not on IPF.

One is SOM the other is ELF, so there is no difference.

If you want me to look at your archive lib, gzip and try to attach it.