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

[Neel2]

Hello,

I could not attache archives since its more than 1MB.

Backgroud: In IPF archive, you can see two times I have added ut.o since, I am getting the unsatisfied errors (only for functions which is defined in ut.c) so i have appended.

Also, I tried menually to append ut.o and it resolves the linking errors, so now my question is what is the difference between these two archives, PA archive works fine on PA architechure where as, on IPF it gives unsatisfied linking errors.

Also, On PA the same function shows extern.

Is there a any known bug with ar on IPF?


Regards,
Neeel

[Dennis Handly]

>I could not attach archives since it's more than 1MB.

That's why I suggested gzip.

>Background: In IPF archive, you can see two times I have added ut.o since, I am getting the unsatisfied errors (only for functions which is defined in ut.c) so i have appended.

How did you create your archive? Adding two copies without -r (replace) isn't a good idea. The best way to create archives is:
rm -f foo.a
ar -r foo.a a1.o a2.o ...
Do not invoke ar(1) multiple times.

>so now my question is what is the difference between these two archives, PA archive works fine on PA architecture whereas, on IPF it gives unsatisfied linking errors.

Basically your original problem was that you were using a foreign devil ar(1) tool. I asked that you remove that broken ar(1) and regenerate each and every archive with the correct ar(1). I assumed that you did it.

If you want to test your archive, use:
$ elfdump -g liboscfe.a

>On PA the same function shows extern.

That's a meaningless difference. It is due to the fact that the SOM format has lots and lots of orthogonal fields (type and scope) and you get more names.

>Is there a any known bug with ar on IPF?

Not if you use the right one.