But, unless the application is statically linked, the location of errno is
not known until application load time; and if it *is* statically linked,
then the location of errno is bound at application build time. It doesn't
seem like this could have changed.
Can you post code that reproduces the problem, and instructions on how to
compile? or if it's large, post it to a website?...or failing that, mail
it to me privately and I'll investigate.
George Wang wrote:
Hi Dan,
I suspect that it is the "errno" storage change in libc.
The code of the part starts to break is like
ret = ::readlink( path, pBuf, pStoreEnd - pBuf );
if ( ret == -1 )
{
if ( errno != EINVAL )
{
//fprintf( stderr, "readlink() errno: %d, != %d\n",
errno, EINVAL );
break;
}
}
else
{
...
}
The truss output shows that readlink("/opt" ...) returns -1 with error
EINVAL.
However the test of "if ( errno != EINVAL )" returns true. I guess that
the location of errno storage has been changed in the libc, so the
application reference errno at a wrong address and get a wrong value.
I tried to debug this issue by dumping debug message to STDERR with
fprintf(), got something similar to the write() function call in the
truss output posted on our forum:
6871: write(2, "\0\0\0\0\0\0\0\0\0\0\0\0".., 18445580) Err#14 EFAULT
So, I guess, the ABI for fprintf in libc has been changed as well.
Best Regards,
George
Dan Mick wrote:
Hi, George, and welcome. Your problem certainly is an interesting one.
Have you identified the difference in the Solaris ABI that makes the
application fail? The previous information wasn't clear about what
had been identified as a change, if anything.
George Wang wrote:
Hi,
I am George from LiteSpeed Technologies.
I'd like to assist to have this issue addressed.
Our lshttpd 32bit x86 binary is built with gcc 2.95.x cross compiler
hosted on a Linux box. The system headers and libraries are extracted
from an Solaris 8 x86 box. The lshttpd binary works well on Solaris
10 official releases and earlier Nevada releases, breaks on recent
Nevada release.
If someone is interested in looking further into the problem, I can
create a test application that reproduce this problem and send the
executable along with the source code to him.
This message posted from opensolaris.org
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
