Is there a way to modify GNU Linker Error Parser options for a headless build?

[jmccabe]

Hi,

We're currently using the CDT headless builder to build our managed projects under Jenkins. We've recently added an extra dependency which gives us a slight issue when we're doing a cross-build for an ARM target.

Basically, at the link stage, we get a load of warnings showing "invalid string offset" and this causes the build to be marked as a failure, even though the executable is created and runs fine.

I've searched for more details on this and it seems like it's due to a bug in GNU binutils prior to 2.33; while the warning is emitted, it sounds like it's a false warning. A patch to fix the problem was created here - https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=baf46cd78048e1b959462567556e1de1ef6b9039.

Unfortunately, we're not in a position at the moment, to update to a newer version of binutils but, when I uses the Eclipse UI, I can modify the "GNU Linker Error Parser" options to add a pattern that looks like this:

(.*[/\\])?ld(\.exe)?: (.*\.so): (invalid string offset) (.*) (for section .strtab')

and set it to "Ignore" so that the build does not get marked as a failure. While this isn't ideal, it does for the moment (and testing should find whether any issues genuinely arise as a result).

However, I don't know how or if I can change that setting when running a headless build. Is this possible? If so, can someone please help me by suggesting how to do it, or where I can find the details of how to?

I can see a list of command line options to the headless build application in a couple of places but the documentation on a number of those options seems rather sparse.

I can also see, from the CDT sources, that the changes to the GNU Linker Error Parser settings are stored to a file called model.extensions.xml in the .metadata/.plugins/org.eclipse.cdt.core directory of the workspace. That file is loaded in the ErrorParserExtensionsManager class, in loadUserDefinedErrorParsers(), but I can't see any way of injecting any relevant settings into it from the command line.

One potential option would be to keep a copy of that file and, once the workspace is created from the headless build, but before building any projects, push that copy into the relevant place. It's unpleasant, but appears to work.

Do you know an alternative?

We have a long-term plan to try to move to CMake-based projects, but that may take a little time.

Thanks
John

[jonahgraham]

My first instinct was going to be to suggest putting the settings in the .cproject - but I didn't realize that the configuration of the error parser is not part of the project, only the ID of it. That makes it difficult to share error parsers with team members, so that sucks too.

I don't see any code paths in released CDTs to allow what you want. Your analysis of the problem and the code looks pretty complete to me.

One potential option would be to keep a copy of that file and, once the workspace is created from the headless build, but before building any projects, push that copy into the relevant place. It's unpleasant, but appears to work.

This is what I would suggest as a workaround. The only other options is to create your own plug-in that implements the ErrorParser extension point and add that to your Eclipse install.

Would you be able to upgrade to CDT 11 (released in ~1 month) if the situation was improved there? It looks fairly straightforward to add an additional command line option to the headless builder that would take the XML file, and also to add an import/export in the preference page for UI workflows.

[jmccabe]

Thanks for your reply Jonah.

As for CDT 11, we've got a bit of an issue that, at this point, we don't have a solution to, but someone had a play around that looks like it might be promising.

Basically we're using Ubuntu for development but, because of the version of certain tools we're using, we're stuck, for the moment on 16.04. Although I've hacked around with my development system by installing a slightly risky later version of GTK+, which got me as far as Eclipse 2022-03, the rest of the team is using 2020-03 so, if CDT 11 can be installed into those, we might be able to do that, but not if it needs the 2022-06 platform version or later.

I don't expect to get to a desperation point within the next few weeks, so it might be feasible.

The 'promising' bit is that one of the team has managed to install the tool I mentioned onto Ubuntu 2020.04 (I think) using a non-standard way so, if that works out, we may be able to move forward.