Libfile 5.03: exception during library creation

Anyone else seen “Internal error, no stack for trap handler” when creating a library with lots (200+) of small files? It’s OK if I break it down into two smaller ones.

This would appear as if it may be a command line size > initial stack chunk size (4096) issue. Who’da thunk it? Looks like the RootStackSize was reduced from 16k to 4k after C Release 3. I recall having to bump the root stack size up in PipeDream BITD.

I also love the way that _kernel_init goes to the effort of copying the short SWI OS_GetEnv command line using words and the much longer SWI DDEUtils_GetCL command line using bytes.

Yeah, it’s all the DDE tools. See https://www.riscosopen.org/tracker/tickets/529

Suggest that they are recompiled with int __root_stack_size = 16384; to take advantage of the long command line facility that DDEUtils provides. It’s not as if developers using these are short on memory, is it? They’ll still use about 1/10th of the memory of gcc.

Oh, and fix the C library too. ;-)

Anyone else seen “Internal error, no stack for trap handler” when creating a library with lots (200+) of small files?

It builds DeskLib okay (about 515 files), but you need to know the secret bit of magic.

That magic is, simply, don’t do anything weird like trying to pass that lot via the command line (as it’s about 27K). Instead, I build up a file list (“__liblist”), space separated paths, like this:

[…snip hundreds of things…]
<DeskLib_Sources$Dir>.Libraries.Icon.APCS32.o.BarIcon <DeskLib_Sources$Dir>.Libraries.Icon.APCS32.o.BarIconUse <DeskLib_Sources$Dir>.Libraries.Icon.APCS32.o.ButtIsHeld <DeskLib_Sources$Dir>.Libraries.Icon.APCS32.o.ClickWait <DeskLib_Sources$Dir>.Libraries.Icon.APCS32.o.Deselect <DeskLib_Sources$Dir>.Libraries.Icon.APCS32.o.DisposeInd <DeskLib_Sources$Dir>.Libraries.Icon.APCS32.o.FileIcon <DeskLib_Sources$Dir>.Libraries.Icon.APCS32.o.ForceWR <DeskLib_Sources$Dir>.Libraries.Icon.APCS32.o.GetBgCol <DeskLib_Sources$Dir>.Libraries.Icon.APCS32.o.GetDouble <DeskLib_Sources$Dir>.Libraries.Icon.APCS32.o.GetFgCol <DeskLib_Sources$Dir>.Libraries.Icon.APCS32.o.GetInteger <DeskLib_Sources$Dir>.Libraries.Icon.APCS32.o.GetSelect <DeskLib_Sources$Dir>.Libraries.Icon.APCS32.o.GetShade <DeskLib_Sources$Dir>.Libraries.Icon.APCS32.o.GetText
[…snip hundreds more…]

And then I pass it as a file to process, like this:

WimpSlot 4096k
LibFile -c -o <DeskLib$Dir>.o.DeskLib32 -v <DeskLib_Sources$Dir>.__liblist"

Oh, indeed, back in ye olden days before DDEUtils, via files were the only game in town. As still used when building PD and Fireworkz.

Looks really like the CLib is just reading its environment too early, otherwise it could just pop the command line in a temporary heap block.