headers
Jon Merriman | 2 Feb 2004 11:37
Picon
Favicon

Undefined references to G_save_regs_in_stack, GC_find_limit on sparc64-openbsd

Attempting to link any program with libgc results in the following 
errors:

mach_dep.o(.text+0x4): In function `GC_push_regs':
/home/jonm/src/thirdparty/gc6.3alpha4/mach_dep.c:320: undefined 
reference to `GC_save_regs_in_stack'
os_dep.o(.text+0x14): In function `GC_init_netbsd_elf':
/home/jonm/src/thirdparty/gc6.3alpha4/os_dep.c:389: undefined reference 
to `GC_find_limit'

I grepped for GC_find_limit and was unable to find where this function 
was defined. Has this even been implemented yet?

Thanks,
Jon Merriman
Permalink | Reply | 0 comments |
headers
Boehm, Hans | 2 Feb 2004 19:11
Picon
Favicon

RE: Undefined references to G_save_regs_in_stack, GC_find_li mit on sparc64-openbsd

I suspect you're the first one to try that particular platform.

Part of the problem has an obvious fix:

Around line 80 in os_dep.c, NEED_FIND_LIMIT should be defined for
ELF && (OPENBSD || NETBSD), since GC-find_limit is called on
those platforms.  That should take care of GC_find_limit().

GC_save_regs_in_stack is defined in several sparc*.s files.  But
it may be that none of those is quite right for your platform.
And you need to make sure the right one is built.

You should also double-check that the configuration definitions
for SPARC/OPENBSD (around line 910 in gcconfig.h) make sense
for sparc64.

Hans

> -----Original Message-----
> From: gc-bounces@...
> [mailto:gc-bounces@...]On Behalf Of Jon Merriman
> Sent: Monday, February 02, 2004 2:38 AM
> To: gc@...
> Subject: [Gc] Undefined references to G_save_regs_in_stack,
> GC_find_limit on sparc64-openbsd
> 
> 
> Attempting to link any program with libgc results in the following 
> errors:
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steven F. Killen | 2 Feb 2004 19:49
Favicon

compile issues

Greetings,

I'm compiling what seems to be a perfectly straightforward build on Linux
(configure/make).  It chugs along just fine until it actually tries to
compile the shared library, and craps out:

/bin/sh ./libtool --mode=link gcc -fexceptions -I/usr/local/include
-L/usr/local/lib -Wl,-rpath /usr/local/lib -o libgc.la -rpath
/usr/local/lib -version-info 1:2:0 allchblk.lo alloc.lo blacklst.lo
checksums.lo dbg_mlc.lo dyn_load.lo finalize.lo gc_dlopen.lo gcj_mlc.lo
headers.lo aix_irix_threads.lo malloc.lo mallocx.lo mark.lo mark_rts.lo
misc.lo new_hblk.lo obj_map.lo os_dep.lo pcr_interface.lo ptr_chck.lo
real_malloc.lo reclaim.lo solaris_pthreads.lo solaris_threads.lo
specific.lo stubborn.lo typd_mlc.lo backgraph.lo win32_threads.lo
pthread_support.lo pthread_stop_world.lo darwin_stop_world.lo  mach_dep.lo
-lpthread
rm -fr .libs/libgc.la .libs/libgc.* .libs/libgc.*
gcc -shared  allchblk.lo alloc.lo blacklst.lo checksums.lo dbg_mlc.lo
dyn_load.lo finalize.lo gc_dlopen.lo gcj_mlc.lo headers.lo
aix_irix_threads.lo malloc.lo mallocx.lo mark.lo mark_rts.lo misc.lo
new_hblk.lo obj_map.lo os_dep.lo pcr_interface.lo ptr_chck.lo
real_malloc.lo reclaim.lo solaris_pthreads.lo solaris_threads.lo
specific.lo stubborn.lo typd_mlc.lo backgraph.lo win32_threads.lo
pthread_support.lo pthread_stop_world.lo darwin_stop_world.lo mach_dep.lo
-L/usr/local/lib -lpthread  -Wl,-rpath -Wl,-soname -Wl,libgc.so.1 -o
.libs/libgc.so.1.0.2
/usr/local/bin/ld: cannot open libgc.so.1: No such file or directory
collect2: ld returned 1 exit status
gmake[1]: *** [libgc.la] Error 1
gmake[1]: Leaving directory `/usr/build/gc/000/gc6.3alpha4'
(Continue reading)

Permalink | Reply | 3 comments |
headers
Alec Orr | 2 Feb 2004 22:17
Favicon

Re: compile issues


Couple questions:
1.  How are you running the build?  Are you using the configure script 
first?  What parameters do you pass to the configure script?

2.  Which version of linux?

-Alec
WBEM Solutions

Steven F. Killen wrote:

> Greetings,
> 
> I'm compiling what seems to be a perfectly straightforward build on Linux
> (configure/make).  It chugs along just fine until it actually tries to
> compile the shared library, and craps out:
> 
> /bin/sh ./libtool --mode=link gcc -fexceptions -I/usr/local/include
> -L/usr/local/lib -Wl,-rpath /usr/local/lib -o libgc.la -rpath
> /usr/local/lib -version-info 1:2:0 allchblk.lo alloc.lo blacklst.lo
> checksums.lo dbg_mlc.lo dyn_load.lo finalize.lo gc_dlopen.lo gcj_mlc.lo
> headers.lo aix_irix_threads.lo malloc.lo mallocx.lo mark.lo mark_rts.lo
> misc.lo new_hblk.lo obj_map.lo os_dep.lo pcr_interface.lo ptr_chck.lo
> real_malloc.lo reclaim.lo solaris_pthreads.lo solaris_threads.lo
> specific.lo stubborn.lo typd_mlc.lo backgraph.lo win32_threads.lo
> pthread_support.lo pthread_stop_world.lo darwin_stop_world.lo  mach_dep.lo
> -lpthread
> rm -fr .libs/libgc.la .libs/libgc.* .libs/libgc.*
> gcc -shared  allchblk.lo alloc.lo blacklst.lo checksums.lo dbg_mlc.lo
(Continue reading)

Permalink | Reply | 2 comments |
headers
Steven F. Killen | 3 Feb 2004 17:21
Favicon

Re: compile issues

On Mon, 2 Feb 2004, Alec Orr wrote:

>
> Couple questions:
> 1.  How are you running the build?  Are you using the configure script
> first?  What parameters do you pass to the configure script?

just a straight ./configure --prefix=/usr/local; make.  I've got certain
environment variables set to operate from /usr/local (CFLAGS,
CPPFLAGS, LDFLAGS), as that's where most of our shared libraries are.

> 2.  Which version of linux?

It's a Red Hat 9ish environment.

> Steven F. Killen wrote:
>
> > Greetings,
> >
> > I'm compiling what seems to be a perfectly straightforward build on Linux
> > (configure/make).  It chugs along just fine until it actually tries to
> > compile the shared library, and craps out:
> >
> > /bin/sh ./libtool --mode=link gcc -fexceptions -I/usr/local/include
> > -L/usr/local/lib -Wl,-rpath /usr/local/lib -o libgc.la -rpath
> > /usr/local/lib -version-info 1:2:0 allchblk.lo alloc.lo blacklst.lo
> > checksums.lo dbg_mlc.lo dyn_load.lo finalize.lo gc_dlopen.lo gcj_mlc.lo
> > headers.lo aix_irix_threads.lo malloc.lo mallocx.lo mark.lo mark_rts.lo
> > misc.lo new_hblk.lo obj_map.lo os_dep.lo pcr_interface.lo ptr_chck.lo
> > real_malloc.lo reclaim.lo solaris_pthreads.lo solaris_threads.lo
(Continue reading)

Permalink | Reply | 1 comment |
headers
Boehm, Hans | 3 Feb 2004 19:23
Picon
Favicon

RE: compile issues

I just tried a similar build under RedHat 9 with my current tree, and it seems to work
fine.  Nothing in this area changed since 6.3alpha4 (or probably for a while before that).

Based on your log, this seems to be a libtool problem.  The generated link line
effectively ends with

-rpath -soname libgc.so.1

The linker is being told to search for libraries in the directory "-soname" and to link
in the library libgc.so.1 .  In a correct build the -rpath isn't there.

Are you sure you're getting the correct libtool?

Hans

> -----Original Message-----
> From: gc-bounces@...
> [mailto:gc-bounces@...]On Behalf Of Steven F. Killen
> Sent: Tuesday, February 03, 2004 8:21 AM
> To: Alec Orr
> Cc: gc@...
> Subject: Re: [Gc] compile issues
> 
> 
> On Mon, 2 Feb 2004, Alec Orr wrote:
> 
> >
> > Couple questions:
> > 1.  How are you running the build?  Are you using the 
> configure script
(Continue reading)

Permalink | Reply | 501 comments |
headers
Alec Orr | 3 Feb 2004 20:01
Favicon

Re: compile issues


I was able to run the same options using RH 8 (uname -a => Linux <srvr> 
2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 i386 GNU/Linux).

Attached it what the build log looked like.

-Alec

Steven F. Killen wrote:

> On Mon, 2 Feb 2004, Alec Orr wrote:
> 
> 
>>Couple questions:
>>1.  How are you running the build?  Are you using the configure script
>>first?  What parameters do you pass to the configure script?
> 
> 
> just a straight ./configure --prefix=/usr/local; make.  I've got certain
> environment variables set to operate from /usr/local (CFLAGS,
> CPPFLAGS, LDFLAGS), as that's where most of our shared libraries are.
> 
> 
>>2.  Which version of linux?
> 
> 
> It's a Red Hat 9ish environment.
> 
> 
>>Steven F. Killen wrote:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steven F. Killen | 5 Feb 2004 17:39
Favicon

RE: compile issues

On Tue, 3 Feb 2004, Boehm, Hans wrote:

> Are you sure you're getting the correct libtool?

Your assessment seems to be correct; it seems I need to learn more about
libtool.  Thanks for the help.  I imagine once I get libtool going right,
the build should be a snap.

> >
> > On Mon, 2 Feb 2004, Alec Orr wrote:
> >
> > >
> > > Couple questions:
> > > 1.  How are you running the build?  Are you using the
> > configure script
> > > first?  What parameters do you pass to the configure script?
> >
> > just a straight ./configure --prefix=/usr/local; make.  I've
> > got certain
> > environment variables set to operate from /usr/local (CFLAGS,
> > CPPFLAGS, LDFLAGS), as that's where most of our shared libraries are.
> >
> > > 2.  Which version of linux?
> >
> > It's a Red Hat 9ish environment.
> >
> > > Steven F. Killen wrote:
> > >
> > > > Greetings,
> > > >
(Continue reading)

Permalink | Reply | 501 comments |
headers
Steven F. Killen | 6 Feb 2004 11:00
Favicon

RE: compile issues

> > Are you sure you're getting the correct libtool?
>
> Your assessment seems to be correct; it seems I need to learn more about
> libtool.  Thanks for the help.  I imagine once I get libtool going right,
> the build should be a snap.

I can now confirm it.  This basically means that libtool 1.3.4 is broken
with respect to new Automake-built packages, because I had the same issue
with Window Maker, and the upgrade to 1.5.2 fixed that too.

Thanks again!

> > >
> > > On Mon, 2 Feb 2004, Alec Orr wrote:
> > >
> > > >
> > > > Couple questions:
> > > > 1.  How are you running the build?  Are you using the
> > > configure script
> > > > first?  What parameters do you pass to the configure script?
> > >
> > > just a straight ./configure --prefix=/usr/local; make.  I've
> > > got certain
> > > environment variables set to operate from /usr/local (CFLAGS,
> > > CPPFLAGS, LDFLAGS), as that's where most of our shared libraries are.
> > >
> > > > 2.  Which version of linux?
> > >
> > > It's a Red Hat 9ish environment.
> > >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alec Orr | 10 Feb 2004 01:01
Favicon

Has anyone tried using OpenSSL with GC 6.2 in Linux?

RH 8.  GC 6.2 compiled debug w/ posix target, ALL_INTERIOR_POINTERS, 
redirect_malloc, gc-assertions enabled.

Good evening,

I realize there's not much anyone can do (too many variables here), but 
if anyone recalls any pitfalls with using OpenSSL in a GC enabled 
environment, or suggestions , would be greatly appreciated.

We have a test application which makes use of OpenSSL 9.7b (shared lib). 
  When we combine OpenSSL (via GoAhead webserver) with GC, we notice 
many 4100 byte normal blocks which are allocated and never freed.  These 
blocks stay in memory forever, and continue to grow.

One question.  In a GC_dump() there is a field for #_marks_set, to what 
does this refer?

Thank you,
Alec Orr
WBEM Solutions

BEFORE SSL REQEUST:
==================
***Static roots:
 From 0x8049000 to 0x804a000  (temporary)
 From 0x804a000 to 0x805a000  (temporary)
 From 0x40012000 to 0x40013000  (temporary)
 From 0x40017000 to 0x40018000  (temporary)
 From 0x40018000 to 0x40019000  (temporary)
 From 0x40034000 to 0x40039000  (temporary)
(Continue reading)

Permalink | Reply | 0 comments |

Gmane