Subject: Re: glibc problem

From: Alex deVries <[email-masked]>
Date: Wed, 22 Apr 1998 17:13:06 -0400 (EDT)

You can get a functional glibc RPM from the mustang directory (4.9.1 IIRC)
on ftp.linux.sgi.com.

Now, in return, can you point me to a tarball or RPM of a natively built
gcc and binutils?

- a

-- 
Alex deVries
http://www.engsoc.carleton.ca/~adevries/ .
EngSoc, US National Headquarters

On Wed, 22 Apr 1998, Dong Liu wrote:

> Date: Wed, 22 Apr 1998 17:19:13 -0400
> From: Dong Liu <[email-masked]>
> To: [email-masked]
> Subject: glibc problem
> 
> Hi,
> 
> I want to try some pthread program on sgi-linux, this is what I got
> 
> /usr/lib/libpthread.so: undefined reference to `__libc_accept'
> /usr/lib/libpthread.so: undefined reference to `__libc_send'
> /usr/lib/libpthread.so: undefined reference to `__libc_recvfrom'
> /usr/lib/libpthread.so: undefined reference to `__libc_recvmsg'
> /usr/lib/libpthread.so: undefined reference to `__libc_sendmsg'
> /usr/lib/libpthread.so: undefined reference to `__libc_recv'
> /usr/lib/libpthread.so: undefined reference to `__libc_sendto'
> /usr/lib/libpthread.so: undefined reference to `__libc_connect'
> 
> my glibc is glibc-2.0.6-1, so I went ftp.redhat.com downloaded
> glibc-2.0.7, but I can't build it. Where can I found sgi-linux
> specific patches for glibc.
> 
> Dong.
>

---

From: Dong Liu <[email-masked]>
Date: Wed, 22 Apr 1998 17:19:13 -0400

Hi,

Dong.

---

From: [email-masked]
Date: Wed, 22 Apr 1998 23:43:20 +0200

> Now, in return, can you point me to a tarball or RPM of a natively built

ftp.linux.sgi.com:/pub/redhat/redhat-4.9.1/mips{el}-linux/binutils-*.rpm
ftp.linux.sgi.com:/pub/redhat/redhat-5.0/mips{el}/gcc-*.rpm.

((Where else?)

Alex, still working on porting Redhat 5.0?  5.1 ante portas ...

  Ralf

---

From: Dong Liu <[email-masked]>
Date: Wed, 22 Apr 1998 17:48:21 -0400

> Now, in return, can you point me to a tarball or RPM of a natively built

I'm using glibc from mustang, apparently the pthread support is broken.
(I have checked that all the __lib_xxx symbols are there in i386 version).

The gcc and binutils I also got from mustang directory.

Dong.

---

From: Alex deVries <[email-masked]>
Date: Wed, 22 Apr 1998 22:23:35 -0400 (EDT)

> ftp.linux.sgi.com:/pub/redhat/redhat-5.0/mips{el}/gcc-*.rpm.

Well, *that* wasn't very bright of me.  Cool, my machine will be up and
running soon.

> Alex, still working on porting Redhat 5.0?  5.1 ante portas ...

When the 5.1 SRPMs start rolling out by the end of the month, I'll start
building them. I'vea 'spare' 3GB SCSI disk, so things should be a lot
easier to do than last time. It would be ultra cool if we could get the
whole thing ported over a number of days after RH 5.1 comes out.

Alan, is there any chance you could free up the build scripts that Red Hat
uses to do the distribution builds?

Hm.  I also have a Mac IIcx to distract me.

- Alex

---

From: [email-masked]
Date: Thu, 23 Apr 1998 05:04:47 +0200

> /usr/lib/libpthread.so: undefined reference to `__libc_connect'

Thanks for your report.  An untested patch to be applied to
libc/sysdeps/unix/sysv/linux/mips/syscalls.list is attached below.

> specific patches for glibc.

You can find the patches In the rpm packages on ftp.linux.sgi.com.

I don't know if the MIPS patches for glibc 2.0.6 are working for 2.0.7.
Unless I missed the announcement 2.0.7 hasn't been released yet and I
don't try to follow the beta releases, no time ...

  Ralf

Index: unix/sysv/linux/mips/syscalls.list
===================================================================
RCS file: /disk2/cvs/libc/sysdeps/unix/sysv/linux/mips/syscalls.list,v
retrieving revision 1.1
diff -u -r1.1 syscalls.list
--- syscalls.list	1997/06/21 23:58:37	1.1
+++ syscalls.list	1998/04/22 06:25:06
@@ -16,19 +16,19 @@
 # Socket functions; Linux/MIPS doesn't use the socketcall(2) wrapper;
 # it's provided for compatibility, though.
 #
-accept		-	accept		3	__accept	accept
+accept		-	accept		3	__libc_accept	__accept accept
 bind		-	bind		3	__bind		bind
-connect		-	connect		3	__connect	connect
+connect		-	connect		3	__libc_connect	__connect connect
 getpeername	-	getpeername	3	__getpeername	getpeername
 getsockname	-	getsockname	3	__getsockname	getsockname
 getsockopt	-	getsockopt	5	__getsockopt	getsockopt
 listen		-	listen		2	__listen	listen
-recv		-	recv		4	__recv		recv
-recvfrom	-	recvfrom	6	__recvfrom	recvfrom
-recvmsg		-	recvmsg		3	__recvmsg	recvmsg
-send		-	send		4	__send		send
-sendmsg		-	sendmsg		3	__sendmsg	sendmsg
-sendto		-	sendto		6	__sendto	sendto
+recv		-	recv		4	__libc_recv	__recv recv
+recvfrom	-	recvfrom	6	__libc_recvfrom	__recvfrom recvfrom
+recvmsg		-	recvmsg		3	__libc_recvfrom	__recvmsg recvmsg
+send		-	send		4	__libc_send	__send send
+sendmsg		-	sendmsg		3	__libc_sendmsg	__sendmsg sendmsg
+sendto		-	sendto		6	__libc_sendto	__sendto sendto
 setsockopt	-	setsockopt	5	__setsockopt	setsockopt
 shutdown	-	shutdown	2	__shutdown	shutdown
 socket		-	socket		3	__socket	socket

---

From: [email-masked]
Date: Thu, 23 Apr 1998 05:17:57 +0200

> Well, *that* wasn't very bright of me.  Cool, my machine will be up and

*grin*

> whole thing ported over a number of days after RH 5.1 comes out.

Ok.  In that case we should add a fat readme that RH 5.0 is incomplete and
4.9.1 should be used or maybe even rm -rf redhat-5.0/.  It's confusing
people.

> Hm.  I also have a Mac IIcx to distract me.

Your Indy is _way_ faster than that brick ;-)

  Ralf

---

From: Alex deVries <[email-masked]>
Date: Wed, 22 Apr 1998 23:28:52 -0400 (EDT)

> 4.9.1 should be used or maybe even rm -rf redhat-5.0/.  It's confusing

Yes, it is confusing.  Especially because there are just gaping holes in
packages (like glibc) for 5.0.  

But I wouldn't say that 5.0 is broken, just that the missing things need
to come from 4.9.1.

Anyway, it'll all be fixed when we go through and redo all of 5.1.  We can
make sure that we include everything like glibc.

> Your Indy is _way_ faster than that brick ;-)

It's amazing how hack value can outshine performance. Some people think
it's what keeps the i386 port of Linux alive.

- Alex

---

From: Dong Liu <[email-masked]>
Date: Fri, 24 Apr 1998 12:00:32 -0400

> don't try to follow the beta releases, no time ...

Nope, after 4 hours building new glibc, it gives me same error for
undefined reference to __libc_accept ... :=*(.

Another bug is invokinf "/lib/ld.so.1 --verify " gives segmentation
fault, so ldd dosn't work.

BTW, I get glibc 2.0.7 from redhat's updates directory.

Dong.

---

From: [email-masked]
Date: Tue, 28 Apr 1998 01:33:50 +0200

On Mon, Apr 27, 1998 at 07:37:42PM -0400, Dong Liu wrote:

> Sorry, I didn't install it properly, now my program links, but it
> still give segementation fault.

Ok.  I have to admit that I never tested any kind of multithread application.
If you could provide the code for the program in question, that'd be
helpful.

  Ralf

---

From: Dong Liu <[email-masked]>
Date: Mon, 27 Apr 1998 19:37:42 -0400

Dong.

BTW, can some one make a tarball of strace and gdb, I don't think I
can check them out from CVS.

---

From: Dong Liu <[email-masked]>
Date: Tue, 28 Apr 1998 15:11:31 -0400

> If you could provide the code for the program in question, that'd be

How about this

---- create-thread.c----

#include <pthread.h>
#include <stdio.h>

void* new_thread(void* arg)
{
	int i;
	printf("Thread[%s] stack at %x\n",arg, &i);
	for (i = 0; i< 4; i++) {
	    printf("Thread[%s] %d\n", arg, i);
	    sched_yield();
	}
	return(NULL);
}

#define NUM_OF_THREAD 100
main(int argc, char **argv)

{
        int num = NUM_OF_THREAD;
	pthread_t thread[NUM_OF_THREAD];
	
	char *args[NUM_OF_THREAD];
	int i;
	int last;
	void *status;

	if (argc > 1)
	    num = atoi(argv[1]);
	if (num>100)
	    num = 100;
	printf("Original thread stack at %x\n", &i);

	for (i = 0 ; i < num; i++) {
	    args[i] = (char *)malloc(80);
	    sprintf(args[i], "%04d", i);
	    if (pthread_create(&thread[i],
			       NULL,
			       new_thread, (void *)args[i])) {
		printf("Error: creating new thread[%d]\n", i);
		break;
	    }
	}

	last = i;

	for (i = 0 ; i < last; i++) {
	    pthread_join(thread[i], &status);
	    printf("thread[%d] return status' address %p\n",i, status);
	}
	printf("%d threads created\n", last);
	exit(0);
}