Ignore my last mail ..

I found the problem, I was updating / copying ld.elf_so from inside the
bash which is also a dynamically linked binary and so it was leading to
this screw up !

please ignore last mail.

moral of story: I have to sleep more now !
-:))

Thanks,
Nitin
---------------------- Forwarded by Nitin Mahajan/HSS on 03/30/2004 05:54
PM ---------------------------


Nitin Mahajan
03/30/2004 12:13 PM

To:    Manuel Bouyer <bouyer@antioche.eu.org>, tege@king.swox.se
cc:    netbsd-bugs@NetBSD.org, tech-kern@netbsd.org

Subject:    problem misc: 23374 ? still not being able to get it working ..
       (Document link: Nitin Mahajan)

Hi,

(this is in relation to earlier fixed undefined PLT symbol problem in ld.)

I am having a problem,
we are running netbsd on our product, it is having a memory based file
system.

I verified that if on my build machine / standalone machine, if I just
expand the base.tgz over the 1.6.1 installation we were currently having.
programs compiled beforehand are running properly.

But, due to some limitations I cannot release / expand all the files in
this released label (of base.tgz )by the author,
I just updated ld.elf_so over the current /usr/libexec and any program
started after this is hanging !
I wrote a simple printf("Hello world \n") and even that is hanging.

Could somebody provide some direction to is ld.elf_so good enough for this
fix ? or do I need to replace something else also ??
Are libs (/usr/libs) also needed to be updated ?? I will put those also,
but why should these be needed.
as from what I understand, ld.elf_so should just be using the info from the
libraries and map them, has some change been done in their stucture also ..
reason for asking this is that our system also has some dynamically linked
libararies built, so we will have to rebuild those also ??

Could some body please explain as to what / how was this fix done. so that
people like me can have a better idea in a situation like I am to make
debugging time least.

there's got to be some file in base.tgz which made things work fine on
standalone netbsd pc ..

( We are having an i386 build, if it will matter. )

Regards,
Nitin



Manuel Bouyer <bouyer@antioche.eu.org> on 03/26/2004 02:15:59 AM

To:    Nitin Mahajan/HSS@HSS
cc:    netbsd-bugs@NetBSD.org

Subject:    Re: problem misc: 23374


On Tue, Mar 23, 2004 at 10:56:34AM +0530, nmahajan@hss.hns.com wrote:
>
>
>
>
> Hi Manuel,
>
> I am just obersving udefined PTL symbols randomly on our machine ..
> I am downloading and applying the rc2 patch which fixes this problem.
> But, I have  a kernel which has lots of changes over 1.6 and it will be
> tough to merge those with this downloaded version.
>
> I learn that there have been ABI changes also, but wasnt sure if there
are
> changes between 1.6.1 we have as our base and 1.6.1.rc2 , are there ?

No there shouldn't be any.

> is it possible /  logical if I download and overwrite this patch over a
> vanilla 1.6.1 and get / use only the relavant files from new compiled
> netbsd ?

Yes, it should be possible

> (if yes, what files would these be ?)

/usr/libexec/ld.elf_so

Or you can just use the ld.elf_so from the 1.6.2 distribution.

But I'm not sure this is fixed in 1.6.2. I had to use a current ld.elf_so
on my alpha to get rid of this. The current ld.elf_so is fine on my 1.6.2
alpha, but I don't know how it would be on i386.

--
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
 --






"DISCLAIMER: This message is proprietary to Hughes Software Systems Limited
(HSS) and is intended solely for the use of the individual to whom it is
addressed. It may contain  privileged or confidential information and
should not be circulated or used for any purpose other than for what it is
intended. If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient, you are
notified that you are strictly prohibited from using, copying, altering, or
disclosing the contents of this message. HSS accepts no responsibility for
loss or damage arising from the use of the information transmitted by this
email including damage from virus."