[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 3/3][DejaGNU] target: Wrap linker flags into `-largs'/`-margs
From: |
Maciej W. Rozycki |
Subject: |
Re: [PATCH 3/3][DejaGNU] target: Wrap linker flags into `-largs'/`-margs' for Ada |
Date: |
Thu, 16 May 2019 12:58:49 +0000 |
On Wed, 15 May 2019, Jacob Bachmeyer wrote:
> This patch really exposes a significant deficiency in our current
> implementation of default_target_compile: the order of various flags
> can be significant, but we only have that order implicitly expressed in
> the code, which goes all the way back to (of course) the "Initial
> revision" that is probably from a time before Tcl had the features that
> will allow significant cleanup in here.
I suspect the origins may be different, however as valuable as your
observation is functional problems have precedence over issues with code
structuring, so we need to fix the problem at hand first. I'm sure
DejaGNU maintainers will be happy to review your implementation of code
restructuring afterwards.
> Some of these could probably be combined and I may have combined
> categories that should be separate in the above list. The GNU toolchain
> has always been a kind of "magic box that just works" (until it doesn't
> and the manual explains the problem) for me, so I am uncertain what the
> ordering rules for combining these categories should be. Anyone know
> the traditional rules and, perhaps more importantly, what systems need
> which rules?
The ordering rules are system-specific I'm afraid and we have to be
careful not to break working systems out there. People may be forced to a
DejaGNU upgrate, due to a newer version of a program being tested having
such a requirement, and can legitimately expect their system to continue
working.
NB I have been repeatedly observing cases where a forced upgrade of a
system component I neither care nor I am competent about, triggered by an
upgrade of a component I do care about, caused the system to malfunction
in a way that I find both unacceptable and extremely hard to debug. It
seems to have become more frequent in the recent years, and I find this
both very frustrating and have wasted lots of time trying to fix the
damage caused. I would therefore suggest to take all the measures
possible to save people from going through such an experience.
FWIW,
Maciej
[PATCH 1/3][GCC] gnatmake: Accept the `--sysroot=' GCC driver option, Maciej W. Rozycki, 2019/05/14
[PATCH 2/3][GCC] GNAT/testsuite: Pass the `ada' option to target compilation, Maciej W. Rozycki, 2019/05/14