glibc problem

glibc problem

[Dong Liu]

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.

Re: glibc problem

[Alex deVries]

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 <dliu@npiww.com>
> To: linux@cthulhu.engr.sgi.com
> 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.
> 

Re: glibc problem

[ralf]

On Wed, Apr 22, 1998 at 05:13:06PM -0400, Alex deVries wrote:

> 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?

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

Re: glibc problem

[Alex deVries]

On Wed, 22 Apr 1998 ralf@uni-koblenz.de wrote:
> On Wed, Apr 22, 1998 at 05:13:06PM -0400, Alex deVries wrote:
> > Now, in return, can you point me to a tarball or RPM of a natively built
> > gcc and binutils?
> 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?)

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

Re: glibc problem

[ralf]

On Wed, Apr 22, 1998 at 10:23:35PM -0400, Alex deVries wrote:

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

*grin*

> > 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.

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.

> 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.

Your Indy is _way_ faster than that brick ;-)

  Ralf

Re: glibc problem

[Alex deVries]

On Thu, 23 Apr 1998 ralf@uni-koblenz.de wrote:
> > > 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.
> 
> 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.

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.

> > Hm.  I also have a Mac IIcx to distract me.
> 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

Re: glibc problem

[Dong Liu]

Alex deVries writes:
 > 
 > 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?
 > 

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.

Re: glibc problem

[ralf]

On Wed, Apr 22, 1998 at 05:19:13PM -0400, Dong Liu wrote:

> 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'

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

> 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.

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

Re: glibc problem

[Dong Liu]

ralf@uni-koblenz.de writes:
 > 
 > Thanks for your report.  An untested patch to be applied to
 > libc/sysdeps/unix/sysv/linux/mips/syscalls.list is attached below.
 > 
 > > 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.
 > 
 > 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

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.

Re: glibc problem

[Dong Liu]

Dong Liu writes:
 > ralf@uni-koblenz.de writes:
 >  > 
 >  > Thanks for your report.  An untested patch to be applied to
 >  > libc/sysdeps/unix/sysv/linux/mips/syscalls.list is attached below.
 >  > 
 >  > > 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.
 >  > 
 >  > 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
 > 
 > Nope, after 4 hours building new glibc, it gives me same error for
 > undefined reference to __libc_accept ... :=*(.
 > 

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

Dong.

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

Re: glibc problem

[ralf]

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

Re: glibc problem

[Dong Liu]

ralf@uni-koblenz.de writes:
 > 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
 > 

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);
}

Re: glibc problem

[Dong Liu]

This what I found out:

The library verion from the root filesystem on ftp.linux.sgi.com

libc 2.0.4  libpthread  0.6

The version og glibc RPM from redhat 4.9.1

libc 2.0.6 libpthread 0.7

If I use libc-2.0.6 and libpthread-0.7, ld complains some missing
symbols, if I use libc-2.0.6 and libpthread-0.6, I get Segmentation
Fault:=(.

Dong.

BTW, is there a X server for sgi-linux?

Glibc Problem

[Ian Chilton]

Hello,

I am having this problem cross-compiling todays CVS glibc:

../sysdeps/generic/dl-cache.c: In function `_dl_load_cache_lookup':
../sysdeps/generic/dl-cache.c:177: warning: large integer implicitly truncated to unsigned type
../sysdeps/generic/dl-cache.c:181: `CACHEMAGIC_VERSION_NEW' undeclared (first use in this function)
../sysdeps/generic/dl-cache.c:181: (Each undeclared identifier is reported only once
../sysdeps/generic/dl-cache.c:181: for each function it appears in.)
make[2]: *** [/crossdev-build/mips-linux/glibc-001025-obj/elf/dl-cache.o] Error 1
make[2]: Leaving directory `/crossdev-build/src/glibc-001025/elf'
make[1]: *** [elf/subdir_lib] Error 2
make[1]: Leaving directory `/crossdev-build/src/glibc-001025'
make: *** [all] Error 2


It worked the other day  :-)
 

Bye for Now,

Ian


                     \|||/ 
                     (o o)
 /----------------ooO-(_)-Ooo----------------\
 |  Ian Chilton                              |
 |  E-Mail : ian@ichilton.co.uk              |
 \-------------------------------------------/

Re: Glibc Problem

[Keith M Wesolowski]

On Wed, Oct 25, 2000 at 04:06:51PM +0100, Ian Chilton wrote:

> I am having this problem cross-compiling todays CVS glibc:
> ../sysdeps/generic/dl-cache.c:181: `CACHEMAGIC_VERSION_NEW' undeclared (first use in this function)

A simple platform-independent typo. I'm sure it'll be fixed soon. In
the meantime here's a patch.

Index: dl-cache.c
===================================================================
RCS file: /cvs/glibc/libc/sysdeps/generic/dl-cache.c,v
retrieving revision 1.25
diff -u -r1.25 dl-cache.c
--- dl-cache.c	2000/10/25 08:07:18	1.25
+++ dl-cache.c	2000/10/25 15:41:06
@@ -178,13 +178,13 @@
 
 	  cache_new = (struct cache_file_new *) ((void *) cache + offset);
 	  if (cachesize < (offset + sizeof (struct cache_file_new))
-	      || memcmp (cache_new->magic, CACHEMAGIC_VERSION_NEW,
-			 sizeof CACHEMAGIC_VERSION_NEW - 1) != 0)
+	      || memcmp (cache_new->magic, CACHEMAGIC_NEW,
+			 sizeof CACHEMAGIC_NEW - 1) != 0)
 	    cache_new = (void *) -1;
 	}
       else if (file != NULL && cachesize > sizeof *cache_new
-	       && memcmp (cache_new->magic, CACHEMAGIC_VERSION_NEW,
-			  sizeof CACHEMAGIC_VERSION_NEW - 1) == 0)
+	       && memcmp (cache_new->magic, CACHEMAGIC_NEW,
+			  sizeof CACHEMAGIC_NEW - 1) == 0)
 	{
 	  cache_new = file;
 	  cache = file;


-- 
Keith M Wesolowski			wesolows@chem.unr.edu
University of Nevada			http://www.chem.unr.edu
Chemistry Department Systems and Network Administrator

Re: Glibc Problem

[Andreas Jaeger]

>>>>> Ian Chilton writes:

 > Hello,
 > I am having this problem cross-compiling todays CVS glibc:

Better ask on the glibc list - and there'll you find a patch already.

check the archives of libc-alpha on: http://sources.redhat.com/glibc

 > It worked the other day  :-)
And will work tomorrow ;-) 

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

glibc problem

[Andre.Messerschmidt]

Hi.

During compilation of glibc 2.2.3  I get the following error:
Can not represent BFD_RELOC_16_PCREL_S2 relocation in this object file
format

Someone in the archives meant that -D__PIC__ should be included to the
CFLAGS to resolve this problem, but it seams that I am too dumb to do this. 
I tried several locations to set the variable in the Makefiles and used the
configparms file to set it, but nothing worked. Then I tried to define it in
the file where the error occured, just to realize that there are more
locations where this define is needed, so I reckon it would be the best to
define it from the beginning.
Can anybody tell me how to get it right? 

best regards
--
Andre Messerschmidt

Application Engineer
Infineon Technologies AG

Re: glibc problem

[Ralf Baechle]

On Thu, Jul 26, 2001 at 11:09:37AM +0200, Andre.Messerschmidt@infineon.com wrote:

> During compilation of glibc 2.2.3  I get the following error:
> Can not represent BFD_RELOC_16_PCREL_S2 relocation in this object file
> format
> 
> Someone in the archives meant that -D__PIC__ should be included to the
> CFLAGS to resolve this problem, but it seams that I am too dumb to do this. 
> I tried several locations to set the variable in the Makefiles and used the
> configparms file to set it, but nothing worked. Then I tried to define it in
> the file where the error occured, just to realize that there are more
> locations where this define is needed, so I reckon it would be the best to
> define it from the beginning.
> Can anybody tell me how to get it right? 

Adding -D__PIC__ is a kludge; the compiler should do it by default.  It
means you're using some non-Linux/MIPS compiler which you should replace.

  Ralf