AdaCore / gprbuild

GPRbuild is an advanced build system designed to help automate the construction of multi-language systems.
Other
65 stars 21 forks source link

Fix rpath bug - check that Run_Path_Origin is set before using #63

Closed Richard-Wai closed 4 years ago

Richard-Wai commented 4 years ago

Bootstrap of gprbuild on FreeBSD created a gprbuild which failed due to a Constraint_Error exception when attempting to look up No_Name (0) Name_Id's string. The failure occurred when an attempt is made to reference the Config.Run_Path_Origin value of a project.

Adding logic to first check that this property is set, a similar issue appeared with an attempt to deference a null String access type for the same "run path origin" when generating a relative path.

CLAassistant commented 4 years ago

CLA assistant check
All committers have signed the CLA.

t-14 commented 4 years ago

Richard, thank you for your contribution. Adding defensive code there is definitely a good idea, but before we merge your PR, may I ask you to have a glance at share/gprconfig/linker.xml and validate all discrepancies between FreeBSD and Linux that you'll find in there? We are not using FreeBSD in-house, so I am wondering if there are cases where those discrepancies are maybe not justified? Thanks in advance!

Richard-Wai commented 4 years ago

Thanks for the pointer! That explains why Run_Path_Origin was not set in the first place. It turns out that in most installations of FSF GNAT on FreeBSD, one will have the gnu linker installed. Even if not, the native linker is the LLVM linker. In both cases, the rpath handling should be the same as Linux. I've consolidated the FreeBSD handling of Run_Path_X with Linux and QNX. I've done a full build of xmlada, gprbuild, and gnatcoll-core, as well as some internal projects. It all seems to work correctly.

t-14 commented 4 years ago

Thanks for looking at it for us. This config chunk hasn't been touched since 2009 at least, so it's not surprising things didn't stand still.