[cc65] Emitting data into segments defined in an interleaved way, while maintaining addresses?

I've run into a bit of trouble with a technique I'd like to apply to the 
way I handle messages in some assembler code.  The way I'd like to 
operate is this:

I have three tables that define message strings.  They are:
1) a table of strings (of variable lengths, 255 byte limit)
2) a table of string lengths (each length is a 1-byte value)
3) a table of addresses of the strings

This all works well if all three tables are part of the same, contiguous 
assembly file.  But I'd like to break these up into separate files, and 
pick and choose which ones get included in various situations.  So I'd 
like to end up with files like this:

File1.asm:
.segment "MESSAGES"
	M11: asc "1A"
	M11_END =*
	M12: asc "1B"
	M12_END =*
.segment "MSGLEN"
	.byte M11_END-M11
	.byte M12_END-M12
.segment "MSGTABLE"
	.addr M11,M12

File2.asm:
.segment "MESSAGES"
	M21: asc "2A"
	M21_END =*
	M22: asc "2B"
	M22_END =*
.segment "MSGLEN"
	.byte M21_END-M21
	.byte M22_END-M22
.segment "MSGTABLE"
	.addr M21,M22

I link everything with this config file:
MEMORY {
     RAM: start = $0800, size = $6500, define = yes, file = %O;
}
SEGMENTS {
     CODE: load = RAM, type = ro;
     MESSAGES: load = RAM, type = ro;
     MSGLEN: load = RAM, type = ro;
     MSGTABLE: load = RAM, type = ro;
     RODATA: load = RAM, type = ro;
     BSS: load = RAM, type = bss;
}

I see that the linker does in fact re-pack the various segments together 
as expected - effectively un-interleaving them.  But the addresses in 
MSGTABLE after File1.asm are incorrect.  The addresses in the output 
from File2.asm are actually relative to the file when it got assembled 
(vs. linked), which are different at link time once the re-packing occurred.

I could probably fix this by having two files per message "package" - 
and include all message text/lengths first, followed by all message 
addresses.  But I'd like to keep all related messages, lengths, and 
addresses together in single files.

I realize there are at least a million other ways to deal with strings. 
  I'd like to maintain this scheme (3 tables) since a fairly large 
codebase is already using it this way.  Aside from custom file 
processing to generate a single file out of several at build time, is 
there a way I can convince the toolchain to do what I want with separate 
files like this?

- David
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.