Linking error with 8l, guys, could you tell me where to look?

[keystroke]

The message is:

(2050) DATA opnames<1>+116(SB)/4,$string<1>+739(SB)
memccpy: multiple initialization
(2170) DATA etnames<1)+72(SB)/4,$string<1>+912(SB)
memccpy: multiple initialization

I know 2050 is somehow related to the line number where opnames appear in the code, and so is 2170 with etnames.
I know it's suggesting I had an opnames initialized some where, but I just don't know where to look. I read the 8l man, but it seems there is no other docs where I can check for detail information.
Can anybody tell me what the rest number of the message means, where should I look for the duplicate code?

Many thanks guys.

[erik quanstrom]

Post by keystroke
(2050) DATA opnames<1>+116(SB)/4,$string<1>+739(SB)
memccpy: multiple initialization
(2170) DATA etnames<1)+72(SB)/4,$string<1>+912(SB)
memccpy: multiple initialization
I know 2050 is somehow related to the line number where opnames appear in the code, and so is 2170 with etnames.
I know it's suggesting I had an opnames initialized some where, but I just don't know where to look. I read the 8l man, but it seems there is no other docs where I can check for detail information.
Can anybody tell me what the rest number of the message means, where should I look for the duplicate code?

this is the format from 8l/list.c:/^Pconv

snprint(str, sizeof(str), "(%ld) %A %D,%D",
p->line, p->as, &p->from, &p->to);

it looks like memccpy is defined twice in the same .8.
i'd look for the symbol rather than the line number.

the format of the line number doesn't fit the plumbable
convention, which would be file:line, and also appears to
not be the line number you are expecting. it's
the line number after include files are processed. which
while not wrong, is not helpful either.

- erik

---
example:

; cat mdef.c
#include <u.h>
#include <libc.h>

void
x(void)
{
}

void
x(void)
{
}

void
main(void)
{
}
; tmk mdef.c
6c -FVTw mdef.c
6l -o 6.mdef mdef.6
x: mdef.6: redefinition: x
(818) TEXT x+0(SB),$0
; # modified 8c to output line numbers in comments
; /sys/src/cmd/8c/6.out -S mdef.c
TEXT x+0(SB),0,$0 /* 806 */
RET , /* 808 */
TEXT x+0(SB),0,$0 /* 811 */
RET , /* 813 */
TEXT main+0(SB),0,$0 /* 816 */
RET , /* 818 */
END , /* 818 */

[keystroke]

Thank you for your reply, erik.

But I don't quite follow you. Are you suggesting that the error has nothing to do with "opnames" and "etnames", but is about the following word "memccpy"?

I had grep opnames and etnames before, and finds only one initial place.
And I grep memccpy, no result was found.
There is a strange situation, when I "8l subr.c" then it's "memccpy", when I
"8l *.8", it shows "create":

(2050) DATA ...(same as before)
create: multiple initialization.
...(same as before)
create: multiple initialization.

I suspect it is opnames and etnames that cause the problem, and I find something
strange in the subr.c and it's included file go.h, is it relevant?

=============================================================

subr.c

=============================================================
static char*
opnames[] =
{
[OADDR] = "ADDR",
[OADD] = "ADD",
[OANDAND] = "ANDAND",
[OAND] = "AND",
[OARRAY] = "ARRAY",
[OASOP] = "ASOP",
[OAS] = "AS",
[OBAD] = "BAD",
[OBREAK] = "BREAK",
[OCALL] = "CALL",
[OCALLPTR] = "CALLPTR",
[OCALLMETH] = "CALLMETH",
[OCALLINTER] = "CALLINTER",
[OCAT] = "CAT",
[OCASE] = "CASE",
[OXCASE] = "XCASE",
[OFALL] = "FALL",
[OCONV] = "CONV",
[OCOLAS] = "COLAS",
[OCOM] = "COM",
[OCONST] = "CONST",
[OCONTINUE] = "CONTINUE",
[ODCLARG] = "DCLARG",
[ODCLCONST] = "DCLCONST",
[ODCLFIELD] = "DCLFIELD",
[ODCLFUNC] = "DCLFUNC",
[ODCLTYPE] = "DCLTYPE",
[ODCLVAR] = "DCLVAR",
[ODIV] = "DIV",
[ODOT] = "DOT",
[ODOTPTR] = "DOTPTR",
[ODOTMETH] = "DOTMETH",
[ODOTINTER] = "DOTINTER",
[OEMPTY] = "EMPTY",
[OEND] = "END",
[OEQ] = "EQ",
[OFOR] = "FOR",
[OFUNC] = "FUNC",
[OGE] = "GE",
[OPROC] = "PROC",
[OGOTO] = "GOTO",
[OGT] = "GT",
[OIF] = "IF",
[OINDEX] = "INDEX",
[OINDEXPTR] = "INDEXPTR",
[OINDEXSTR] = "INDEXSTR",
[OINDEXMAP] = "INDEXMAP",
[OINDEXPTRMAP] = "INDEXPTRMAP",
[OIND] = "IND",
[OLABEL] = "LABEL",
[OLE] = "LE",
[OLEN] = "LEN",
[OLIST] = "LIST",
[OLITERAL] = "LITERAL",
[OLSH] = "LSH",
[OLT] = "LT",
[OMINUS] = "MINUS",
[OMOD] = "MOD",
[OMUL] = "MUL",
[ONAME] = "NAME",
[ONE] = "NE",
[ONOT] = "NOT",
[OOROR] = "OROR",
[OOR] = "OR",
[OPLUS] = "PLUS",
[ODEC] = "DEC",
[OINC] = "INC",
[OSEND] = "SEND",
[ORECV] = "RECV",
[OPTR] = "PTR",
[ORETURN] = "RETURN",
[ORSH] = "RSH",
[OSLICE] = "SLICE",
[OSUB] = "SUB",
[OSWITCH] = "SWITCH",
[OTYPE] = "TYPE",
[OVAR] = "VAR",
[OEXPORT] = "EXPORT",
[OIMPORT] = "IMPORT",
[OXOR] = "XOR",
[ONEW] = "NEW",
[OFALL] = "FALL",
[OXFALL] = "XFALL",
[OPANIC] = "PANIC",
[OPRINT] = "PRINT",
[OXXX] = "XXX",
};

=============================================================

go.h

=============================================================
enum
{
OXXX,

OTYPE, OCONST, OVAR, OEXPORT, OIMPORT,

ONAME,
ODOT, ODOTPTR, ODOTMETH, ODOTINTER,
ODCLFUNC, ODCLCONST, ODCLVAR,
ODCLTYPE, ODCLFIELD, ODCLARG,
OLIST,
OPTR, OARRAY,
ORETURN, OFOR, OIF, OSWITCH,
OAS, OASOP, OCOLAS, OCASE, OXCASE, OFALL, OXFALL,
OGOTO, OPROC, ONEW, OPANIC, OPRINT, OEMPTY,

OOROR,
OANDAND,
OEQ, ONE, OLT, OLE, OGE, OGT,
OADD, OSUB, OOR, OXOR, OCAT,
OMUL, ODIV, OMOD, OLSH, ORSH, OAND,
ODEC, OINC,
OLEN,
OFUNC,
OLABEL,
OBREAK,
OCONTINUE,
OADDR,
OIND,
OCALL, OCALLPTR, OCALLMETH, OCALLINTER,
OINDEX, OINDEXPTR, OINDEXSTR, OINDEXMAP, OINDEXPTRMAP,
OSLICE,
ONOT, OCOM, OPLUS, OMINUS, OSEND, ORECV,
OLITERAL,
OCONV,
OBAD,

OEND,
};

[Bence Fábián]

This is a multiple initialization problem. Here is an example code:

#include <u.h>
#include <libc.h>

int num = 20;
int num = 30;

void
main(void)
{
print("%d\n", num);
exits(nil);
}

Post by keystroke
Thank you for your reply, erik.
But I don't quite follow you. Are you suggesting that the error has
nothing to do with "opnames" and "etnames", but is about the following word
"memccpy"?
I had grep opnames and etnames before, and finds only one initial place.
And I grep memccpy, no result was found.
There is a strange situation, when I "8l subr.c" then it's "memccpy", when I
(2050) DATA ...(same as before)
create: multiple initialization.
...(same as before)
create: multiple initialization.
I suspect it is opnames and etnames that cause the problem, and I find something
strange in the subr.c and it's included file go.h, is it relevant?
=============================================================

Post by keystroke
subr.c

=============================================================
static char*
opnames[] =
{
[OADDR] = "ADDR",
[OADD] = "ADD",
[OANDAND] = "ANDAND",
[OAND] = "AND",
[OARRAY] = "ARRAY",
[OASOP] = "ASOP",
[OAS] = "AS",
[OBAD] = "BAD",
[OBREAK] = "BREAK",
[OCALL] = "CALL",
[OCALLPTR] = "CALLPTR",
[OCALLMETH] = "CALLMETH",
[OCALLINTER] = "CALLINTER",
[OCAT] = "CAT",
[OCASE] = "CASE",
[OXCASE] = "XCASE",
[OFALL] = "FALL",
[OCONV] = "CONV",
[OCOLAS] = "COLAS",
[OCOM] = "COM",
[OCONST] = "CONST",
[OCONTINUE] = "CONTINUE",
[ODCLARG] = "DCLARG",
[ODCLCONST] = "DCLCONST",
[ODCLFIELD] = "DCLFIELD",
[ODCLFUNC] = "DCLFUNC",
[ODCLTYPE] = "DCLTYPE",
[ODCLVAR] = "DCLVAR",
[ODIV] = "DIV",
[ODOT] = "DOT",
[ODOTPTR] = "DOTPTR",
[ODOTMETH] = "DOTMETH",
[ODOTINTER] = "DOTINTER",
[OEMPTY] = "EMPTY",
[OEND] = "END",
[OEQ] = "EQ",
[OFOR] = "FOR",
[OFUNC] = "FUNC",
[OGE] = "GE",
[OPROC] = "PROC",
[OGOTO] = "GOTO",
[OGT] = "GT",
[OIF] = "IF",
[OINDEX] = "INDEX",
[OINDEXPTR] = "INDEXPTR",
[OINDEXSTR] = "INDEXSTR",
[OINDEXMAP] = "INDEXMAP",
[OINDEXPTRMAP] = "INDEXPTRMAP",
[OIND] = "IND",
[OLABEL] = "LABEL",
[OLE] = "LE",
[OLEN] = "LEN",
[OLIST] = "LIST",
[OLITERAL] = "LITERAL",
[OLSH] = "LSH",
[OLT] = "LT",
[OMINUS] = "MINUS",
[OMOD] = "MOD",
[OMUL] = "MUL",
[ONAME] = "NAME",
[ONE] = "NE",
[ONOT] = "NOT",
[OOROR] = "OROR",
[OOR] = "OR",
[OPLUS] = "PLUS",
[ODEC] = "DEC",
[OINC] = "INC",
[OSEND] = "SEND",
[ORECV] = "RECV",
[OPTR] = "PTR",
[ORETURN] = "RETURN",
[ORSH] = "RSH",
[OSLICE] = "SLICE",
[OSUB] = "SUB",
[OSWITCH] = "SWITCH",
[OTYPE] = "TYPE",
[OVAR] = "VAR",
[OEXPORT] = "EXPORT",
[OIMPORT] = "IMPORT",
[OXOR] = "XOR",
[ONEW] = "NEW",
[OFALL] = "FALL",
[OXFALL] = "XFALL",
[OPANIC] = "PANIC",
[OPRINT] = "PRINT",
[OXXX] = "XXX",
};
=============================================================

Post by keystroke
go.h

=============================================================
enum
{
OXXX,
OTYPE, OCONST, OVAR, OEXPORT, OIMPORT,
ONAME,
ODOT, ODOTPTR, ODOTMETH, ODOTINTER,
ODCLFUNC, ODCLCONST, ODCLVAR,
ODCLTYPE, ODCLFIELD, ODCLARG,
OLIST,
OPTR, OARRAY,
ORETURN, OFOR, OIF, OSWITCH,
OAS, OASOP, OCOLAS, OCASE, OXCASE, OFALL, OXFALL,
OGOTO, OPROC, ONEW, OPANIC, OPRINT, OEMPTY,
OOROR,
OANDAND,
OEQ, ONE, OLT, OLE, OGE, OGT,
OADD, OSUB, OOR, OXOR, OCAT,
OMUL, ODIV, OMOD, OLSH, ORSH, OAND,
ODEC, OINC,
OLEN,
OFUNC,
OLABEL,
OBREAK,
OCONTINUE,
OADDR,
OIND,
OCALL, OCALLPTR, OCALLMETH, OCALLINTER,
OINDEX, OINDEXPTR, OINDEXSTR, OINDEXMAP, OINDEXPTRMAP,
OSLICE,
ONOT, OCOM, OPLUS, OMINUS, OSEND, ORECV,
OLITERAL,
OCONV,
OBAD,
OEND,
};

[erik quanstrom]

you're right. a quick trip through sort|uniq -d says that FALL is listed
twice.

- erik

[keystroke]

圚 2012幎11月28日星期䞉UTC+8䞋午8时22分30秒Bence Fábián写道

but what is _most_ likely is that you really have them initialized two times.
just do
g '(op|et)names ?='
you should find 4 initializations. just delete the redundant ones.
DATA  opnames<1>+116(SB)/4,$string<1>+739(SB)
and
DATA  etnames<1)+72(SB)/4,$string<1>+912(SB)
are the second initializations of both opnames and etnames.
you can grep for them in the output of
8c -S source.c
that's all i can help, cause i can't tell what $string<1>+739(SB) and $string<1>+912(SB) refer to
since they are adresses.

Thanks guys, I just look into the list, and suprisingly saw you replying in
a new thread, I am not familiar with newsgroup and didn't saw your reply earlier
the problem is solved. It's a good lesson, eyes can lie, I just didn't use machine to check duplicated initializaion.

[keystroke]

圚 2012幎11月28日星期䞉UTC+8䞋午8时48分09秒erik quanstrom写道

Post by erik quanstrom
you're right. a quick trip through sort|uniq -d says that FALL is listed
twice.
- erik

Thank you erik and Bence, it's a good lesson to learn.

[keystroke]

圚 2012幎11月28日星期䞉UTC+8䞋午8时48分09秒erik quanstrom写道

Post by erik quanstrom
you're right. a quick trip through sort|uniq -d says that FALL is listed
twice.
- erik

Thank you erik, it's a good lesson.