Compiler error

I'm seeing a compiler error



I've attached the .LSX file.

If I comment line' starting at 26497 in our code this program compiles successfully.



This is EL7 6.5.1739.2
I also tested 7.0.1754.3 with the same result

We're hoping to get a 6.5 version to fix this.

Thanks.

The good news (maybe) is that it seems to compile ok in the current 7.0.1757.1.

Can you give me the details on the error you're getting? And also the compiler / runtime version?

The .lst file contains



This is EL7 6.5.1739.2
COMPIL 6.5(1034)

I also tested 7.0.1754.3 with the same result

Sorry, I guess I overlooked the error in your first post. As for the version, I guess what I had meant to ask was what version you wanted as your baseline target when you way you wanted to get a 6.5 version fix. (Would 6.5.1744 be acceptable? Or does it have to be 1739?.)

I'd be fine with the latest 6.5 as long it doesn't contain 64-bit changes. Those didn't start until 7 as far as I can, and those are the biggest cause of regressions/bugs.

As an aside, what is the plan for the "stable even number release" post 6.5? I would have thought 7.0, but that is taking much longer to stabilize than expected.

Good question. Actually the 64-bit migration has beem in progress for years, starting way way back (5.x?) when we switched to the 64 file i/o functions. But the activity started picking up again in late 2021 (6.5.1708) when we started targeting the Ubuntu platform (which no longer supported the i686 architecture). Another motivation around that time was increasing pressure to support SQL Server from Linux without having to purchase the commercial third-party ODBC connector. The pace picked up around 6.5.1730 (May 2023) when we started switching to newer (64 bit compatible) versions of many of the standard C library functions, which created a ripple effect through all the related structures, and accelerated from there in 1733 thru 1740.

In retrospect maybe we pushed the 7.0 "stable release" a bit too aggressively in order to have it available by the Conference last year, but I think there was a legitimate concern that 6.5 had become too much of a "have it your own way" release, with nearly all the developers treating some arbitrary sub-version as their own stable platform. So the hope was that the 7.0 release would push the critical mass of developers to at least start using it in-house, both to experiment with new features and perhaps more important, to shake out remaining bugs. But as is inevitably the case, developers are too busy to want to spend a lot of time looking for problems, and are mainly motivated to upgrade only if there is some new feature they need to satisfy a pressing requirement (or, for many Linux users, pressure to migrate to a newer OS release.) Which leads to even more updates (as the new features/platforms are the most likely to need further refinements), but not that much attention to legacy compatibility testing. Simultaneously, I've been on a quest to document the internal code, which creates tension between describing what is, vs. refining or even fixing things that reveal themselves when they appear under the microscope. So there's a fair amount of on-going internal clean-up going on, all of it hopefully leading to better stability, but any time you change anything, there is a risk of breaking something. And with our absolute failure to agree on a preferred target Linux platform, deploying and testing any code changes has become a lot more complicated. (It's not unusual, for example, for a problem, or just a suspicious compiler warning to pop up on a particular OS platform/architecture after passing muster on several others before that, leading to an ouroboros-like loop through the different environments to make them all happy. Overall, I think it's several steps forward for every step back, but I don't see any real alternative to continuing on this path. (Starting a 7.1 isn't going to simplify matters for anyone right now.)

Back to the compil problem, I'm still having trouble reproducing it. Here, for example, is my compilation under 6.5.1739.2-el7 ...

Under 7.0.1754.1, I get similar results, although there is a slight difference in the overall program size.

Do you think you might need access to my dev VM?

I guess that's the best option.

I just emailed the connection details.

I've confirmed that the problem occurs even in the latest compiler. But it doesn't occur when compiling the LSX file; it only happens with the original source. That's going to be a bit difficult to track down, given the size and number of modules in this program.

One thing I didn't quite understand though was your comment at the very top of the thread saying that commenting out the lines shown in your excerpt caused the error to go away. The excerpt is from the LSX file, but the LSX file compiles ok even with the lines. And commenting out ++IF directives in the LSX doesn't have much effect because the LSX will compile based on the way those directives were originally evaluated. And if I try to remove that ++include from the actual source, it introduces other legitimate errors.

I was saying that commenting those three lines in our code (not the LSX) allows the program to compile. There is a conditional feature that is enabled if that file is included; which, is needed for one customer, but not another.

I shutdown ngrok on the computer you connected to yesterday. Let me know if you need access again.

I thought I had simulated that operation but apparently didn't do it right. I would like to get back on again, although I'm not yet sure what my plan of attack is going to be. Given that there is no obvious connection between the code that gets commented out and the actual error, and the enormous size of the program (over 2000 ++includes, 380+ of which are unique, 11000+ individual functions...) I definitely need a strategy! Either some kind of customized traces (which will probably involve many cycles of uploading test versions of the compiler), or maybe come up with a way to copy the entire source tree over to my environment where I can more easily work with it.

I can get you a copy of the code. Going to be after lunch.

No rush on my part. But I'm also willing to pull the code over myself to save you the trouble. It looks like there's about a dozen unique include directories and I could just wildcard transfer them to a VM here.

Ok, I got it all set up and am able to reproduce the error here. Now the fun begins. But first, lunch!

I've identified the problem, but haven't yet decided on the solution. It came into being when ++IFDEF was enhanced to treat DEFSTRUCTs like DEFINEd symbols. But while DEFINEs are processed during the initial compiler pass, DEFSTRUCTs are not. Unlike DEFINEs which can easily be cleared at the start of the second pass, or not (since they don't take up any space in the RUN), DEFSTRUCTs are a lot more complex and lead to variables being defined, which do take up space in the RUN. So we don't want to handle them until we're sure which functions are actually going to be included in the RUN, which we don't know until we shake out all the uncalled functions at the end of the first pass.

In your case, the function that was causing the undefined function error was only being called by another function that was dependent on an ++IFDEF INVPRCHIST_CMDHDR where INVPRCHIST_CMDHDR was a DEFSTRUCT. Because the DEFSTRUCT wasn't processed in the first phase, the function calling the one in question wasn't included, causing both the called function and the caller to be shaken out. But in the second pass, the caller got included because the DEFSTRUCT by then had been processed, leaving the call to the missing function, but not the missing function; hence the compiler error. The error doesn't show up in the LSX, because it gets created during the second pass, and because even for functions that are shaken out, the function definition still appears in the LSX. So the LSX compilation completes without error. (The RUN still would be missing the body of the function in question, but in another coincidence, that function was empty of any code anyway, since all of its contents were dependent on ++IF clauses that weren't triggered.)

You could work around the issue by replacing your ++IFDEF <defstruct name> with ++IFDEF <symbol> and add the DEFINE <symbol> next to the DEFSTRUCT. It wouldn't be that easy to find all the potential occurrences of the problem since your DEFSTRUCT names don't look any different than other symbol names. (This is one reason why I prefer to use a common prefix like ST_ in front of DEFSTRUCT names, making them easily distinguishable from other symbols.) On the other hand, it takes a lot of parts to line up in order for the problem to surface, so maybe this one routine is all you need to manually adjust to take the pressure off updating.

In any case, I expect to work out a solution within the next 24 hours or so.

That's an interesting issue. Couldn't have found that without the code I imagine.

I've modified the ++IFDEF to use a DEFINE, and it's compiling now.

You got that right -- I'm not sure I would ever have figured it out otherwise!

Here's a beta release of the update that fixes this problem:

ash-7.0.1757.5-el7-upd.tz
ash70notes.txt

And although it's not related to the compiler issue and not specific to this version, this update of the ashnet library is recommended:

libashnet.so.1.14.194-el7.tz