I'm guessing it's C code (asmlabel.c is part of the C compiler), and a huge amount of code all in one compilation unit ("C file").
The "local label" in this case refers to the throwaway assembly labels generated by the C compiler. The label is local to the compilation unit. For example:
Code:
int main(void) {
static char i, sum;
for(i = 0; i < 10; ++i)
sum += i;
return sum;
}
(
cl65 -Oirs -c --listing loclab.lst loclab.c) =>
Code:
000000r 1 .proc _main: near
000000r 1
000000r 1 .segment "BSS"
000000r 1
000000r 1 L0002:
000000r 1 00 .res 1,$00
000001r 1 L0003:
000001r 1 00 .res 1,$00
000002r 1
000002r 1 .segment "CODE"
000000r 1
000000r 1 A9 00 lda #$00
000002r 1 8D rr rr sta L0002
000005r 1 AD rr rr L000F: lda L0002
000008r 1 C9 0A cmp #$0A
00000Ar 1 B0 0D bcs L0010
00000Cr 1 18 clc
00000Dr 1 6D rr rr adc L0003
000010r 1 8D rr rr sta L0003
000013r 1 EE rr rr inc L0002
000016r 1 4C rr rr jmp L000F
000019r 1 AD rr rr L0010: lda L0003
00001Cr 1 A2 00 ldx #$00
00001Er 1 60 rts
00001Fr 1
00001Fr 1 .endproc
(Some of the labels like L0004 have been removed in the optimization passes.)
The fix is to split your project into more than one compilation unit ("C file"), compile them separately and link. Whether this is easy or hard depends on how your project is structured.
The limit of 65536 labels is probably an artificial one, intended to catch compilations gone awry, so another option would be to persuade the cc65 devs to increase the limit.
EDIT: Changed "file" to "C file" to try to drive home the point that it's not enough to have multiple files and just #include them from one file, that'd still be a single compilation unit.