[9fans] malloc redefinition when linking pcc with 8c programs

[9fans] malloc redefinition when linking pcc with 8c programs

[mirtchov]

I'm having this problem I can't get around -- trying to link .8 files
compiled with ape/pcc and .8 files compiled with 8c I get the
following:

	malloc: /386/lib/libc.a(mallocz): redefinition: malloc
	(1012)	TEXT	malloc+0(SB),$24
	free: /386/lib/libc.a(mallocz): redefinition: free
	(1041)	TEXT	free+0(SB),$12
	realloc: /386/lib/libc.a(mallocz): redefinition: realloc
	(1049)	TEXT	realloc+0(SB),$28
	calloc: /386/lib/libc.a(mallocz): redefinition: calloc
	(1078)	TEXT	calloc+0(SB),$24
	atexit: /386/lib/libc.a(exits): redefinition: atexit
	(776)	TEXT	atexit+0(SB),$16

Any ideas?

andrey

Re: [9fans] malloc redefinition when linking pcc with 8c programs

[Russ Cox]

> I'm having this problem I can't get around -- trying to link .8 files
> compiled with ape/pcc and .8 files compiled with 8c I get the
> following:
>
> 	malloc: /386/lib/libc.a(mallocz): redefinition: malloc
> 	(1012)	TEXT	malloc+0(SB),$24
> 	free: /386/lib/libc.a(mallocz): redefinition: free
> 	(1041)	TEXT	free+0(SB),$12
> 	realloc: /386/lib/libc.a(mallocz): redefinition: realloc
> 	(1049)	TEXT	realloc+0(SB),$28
> 	calloc: /386/lib/libc.a(mallocz): redefinition: calloc
> 	(1078)	TEXT	calloc+0(SB),$24
> 	atexit: /386/lib/libc.a(exits): redefinition: atexit
> 	(776)	TEXT	atexit+0(SB),$16
>
> Any ideas?

you're trying to link the ape library
with the normal c library, and you cannot do that.
one or the other, as discussed earlier.
multiple mallocs aren't the only reason.

Re: [9fans] malloc redefinition when linking pcc with 8c programs

[mirtchov]

> you're trying to link the ape library
> with the normal c library, and you cannot do that.
> one or the other, as discussed earlier.
> multiple mallocs aren't the only reason.

I guess I've misunderstood the original discussion.  no chance for
writing just the graphical portion of a program in libdraw and linking
it against the ape-compiled rest then.  ☹

in this case sorry, no graphical browser for plan9.  until vitanuova
makes limbo and dis available native for plan9 and we all use charon.

andrey

Re: [9fans] malloc redefinition when linking pcc with 8c programs

[Latchesar Ionkov]

What about compiling libdraw (and friends) with pcc?

	Lucho

On Mon, Dec 01, 2003 at 01:00:15PM -0700, mirtchov@cpsc.ucalgary.ca said:
> > you're trying to link the ape library
> > with the normal c library, and you cannot do that.
> > one or the other, as discussed earlier.
> > multiple mallocs aren't the only reason.
>
> I guess I've misunderstood the original discussion.  no chance for
> writing just the graphical portion of a program in libdraw and linking
> it against the ape-compiled rest then.  ???
>
> in this case sorry, no graphical browser for plan9.  until vitanuova
> makes limbo and dis available native for plan9 and we all use charon.
>
> andrey

Re: [9fans] malloc redefinition when linking pcc with 8c programs

[boyd, rounin]

looks like a lot of 'illegal combination of pointer and integer' as pcc once
opined.

Re: [9fans] malloc redefinition when linking pcc with 8c programs

[andrey mirtchovski]

On Mon, 1 Dec 2003, Latchesar Ionkov wrote:

> What about compiling libdraw (and friends) with pcc?
>

as Russ said, it's a pain in the butt...

a more elegant solution would be to change the names of the system calls
"behind the scenes" while linking with ape/libc.a for example malloc becomes
apemalloc. with statically linked binaries that should solve my problem...

unless i'm missing many things.

"links" (the browser) is such a bloated piece of software that a rewrite for
plan9 seems impossible, you saw the font_include.c example already, which
won't even compile under pcc because it runs out of memory :)

andrey

Re: [9fans] malloc redefinition when linking pcc with 8c programs

[Russ Cox]

> On Mon, 1 Dec 2003, Latchesar Ionkov wrote:
>
> > What about compiling libdraw (and friends) with pcc?
> >
>
> as Russ said, it's a pain in the butt...
>
> a more elegant solution would be to change the names of the system calls
> "behind the scenes" while linking with ape/libc.a for example malloc becomes
> apemalloc. with statically linked binaries that should solve my problem...
>
> unless i'm missing many things.
>
> "links" (the browser) is such a bloated piece of software that a rewrite for
> plan9 seems impossible, you saw the font_include.c example already, which
> won't even compile under pcc because it runs out of memory :)

i looked at links for a little while
but since (iirc) it can't display www.nytimes.com
(a seemingly median-difficulty page)
properly, i decided it wasn't worth it.
also the interface is awful.

Re: [9fans] malloc redefinition when linking pcc with 8c programs

[mirtchov]

to be honest, it does a lot of things and it does them reasonably
well, including java script. I don't mind the interface all that much, but I'm not forced to
use links every day.

I remember you being turned off by the large select() loop in the
middle of the code when we first brought it up.  that's why I decided
to attempt to do it with ape.  after sitting in my 'todo' folder for 6
months I spent the two days making it compile cleanly (which involved
way too many casts from unsigned char * to char * and back).  now the
only thing that's left is the driver for Plan 9, which is mostly raw
bitmaps being loaded onto the screen.

i'm contemplating on having the plan9 driver just write the bitmaps to
/dev/draw or to another simple file server that will know how to
display them...

here's how nytimes.com is rendered with the latest (2.1.14) links in
linux:

	http://pages.cpsc.ucalgary.ca/~mirtchov/screenshots/nytimes.png

andrey

ps: and a change to /sys/lib/plumb/basic to plumb png files to
page, now that they're readable with png(1). please add it on sources:

plan9% yesterday -d /sys/lib/plumb/basic
diff /n/dump/2003/1201/sys/lib/plumb/basic /sys/lib/plumb/basic
12c12
< data matches '(https?|ftp|file|gopher|mailto|news|nntp|telnet|wais|prospero)://[a-zA-Z0-9_@\-]+([.:][a-zA-Z0-9_@\-]+)*/?[a-zA-Z0-9_?,%#~&/\-+=]+([:.][a-zA-Z0-9_?,%#~&/\-+=]+)*\.(jpe?g|JPE?G|gif|GIF|ps|PS|pdf|PDF)'
---
> data matches '(https?|ftp|file|gopher|mailto|news|nntp|telnet|wais|prospero)://[a-zA-Z0-9_@\-]+([.:][a-zA-Z0-9_@\-]+)*/?[a-zA-Z0-9_?,%#~&/\-+=]+([:.][a-zA-Z0-9_?,%#~&/\-+=]+)*\.(jpe?g|JPE?G|gif|GIF|png|PNG|ps|PS|pdf|PDF)'
plan9%

Re: [9fans] malloc redefinition when linking pcc with 8c programs

[Hugo Santos]

I find w3m to be much better than links in terms of rendering.

Hugo

Re: [9fans] malloc redefinition when linking pcc with 8c programs

[Russ Cox]

> I find w3m to be much better than links in terms of rendering.

except for the lack of graphics, no?

Re: [9fans] malloc redefinition when linking pcc with 8c programs

[Hugo Santos]

Russ Cox wrote:

>>I find w3m to be much better than links in terms of rendering.
>>
>>
>
>except for the lack of graphics, no?
>
>
>
w3m-img gives w3m image support in linux framebuffer. although i was
talking about text-mode. AFAIK w3m doesn't support other fonts like
links2 does.

Re: [9fans] malloc redefinition when linking pcc with 8c programs

[David Arnold]

-->"Hugo" == Hugo Santos <hugo@innerghost.net> writes:


  Hugo> Russ Cox wrote:
  >>> I find w3m to be much better than links in terms of rendering.

  >>  except for the lack of graphics, no?

  Hugo> w3m-img gives w3m image support in linux framebuffer.

there's a ghastly-but-great hack for w3m in an xterm which alots space
for images in curses and then writes the images themselves to the
underlying X window.





d

Re: [9fans] malloc redefinition when linking pcc with 8c programs

[Russ Cox]

> > you're trying to link the ape library
> > with the normal c library, and you cannot do that.
> > one or the other, as discussed earlier.
> > multiple mallocs aren't the only reason.
>
> I guess I've misunderstood the original discussion.  no chance for
> writing just the graphical portion of a program in libdraw and linking
> it against the ape-compiled rest then.

you'd have to get libdraw compiling using pcc,
meaning make a /sys/include/ape/draw.h, etc.
i don't think it would be a lot of work, but
it's not trivial and could be another copy
to maintain.

it's possible that in the specific case of libdraw
the port would be easy because open(), read(), write(),
etc. mean much the same in ape as they do in native plan 9.

you need not to include libc.h, because it has a
tag informing the linker to link with /386/lib/libc.a,
and you need to do without that library.