14.0 compiler : New unwanted /SUBSYTEM:CONSOLE in main program object code

14.0 compiler : New unwanted /SUBSYTEM:CONSOLE in main program object code

The 14.0 compiler on Windows inserts an unwanted /SUBSYSTEM:CONSOLE switch in the compiled object code of a file containing a main program. This new behaviour is immensely unhelpful when building Windows GUI applications, causing the resulting application to have an ugly and unwanted attached console window, despite correctly specifying /SUBSYSTEM:WINDOWS in the link step. This is a change in behaviour from all previous versions of Visual Fortran going right back to the original DVF 5.0. Using a hex editor to replace the word "CONSOLE" with "WINDOWS" in the object file fixes the problem, but this is a hideous solution. Surely there must be a command line switch to prevent this awful new behaviour? Or is there a switch which allows the subsystem to be specified at compile time? The latter seems completely dumb, since specifying subsystem is meant to be a link time task, but in that case why the heck is the 14.0 compiler inserting this at compile time anyway??

Switches such as /winapp or /MG seem to have no effect and /SUBSYSTEM:WINDOWS specified as a compiler (rather than linker) switch is not rejected as an "unknown option".

The problem is trivially easy to reproduce. Simply compile a trivial one-line main program with the /c switch with 14.0 and dump the resulting object file. The offending /SUBSYSTEM:CONSOLE appears near the start of the object code. Compiled with previous releases no such switch is present (and quite rightly too).

13 posts / novo 0
Último post
Para obter mais informações sobre otimizações de compiladores, consulte Aviso sobre otimizações.

I can see the behavior you describe, and I agree it seems inappropriate. What puzzles me is that it doesn't do this consistently, and that we haven't heard about it before. We'll investigate - thanks.

Steve Intel Developer Support

This was added to better support VS2012 which no longer "assumes" that attribute.  Because it was missing, the use of "link" from the command line, or "xilink" from within Visual Studio was causing build problems with console Fortran programs.

To resolve your problem, please add -switch:fe_no_subsystem, and we'll fix the /MG and /winapp issue asap.

                            -- Lorri

 

Having to specify a new command line switch to suppress behaviour which shouldn't be present in the first place is, in my view, highly unsatisfactory. Subsystem type is something which should, by definition, be specified at link time, not compile time. If there is a problem with console applications in VS2012, then the problem should be solved in project linker switches, not by foisting an unwanted and unspecified linker switch into the object code at compile time.

Fixing /MG and /winapp goes part way to solving the problem, but those switches have never been necessary to create Windows GUI applications with any version of Visual Fortran from DVF 5.0 right through to IVF 13.1. Main programs could be compiled with nothing but the /c switch, leaving /subsystem:windows to be (correctly) specified at link time and a suitable WinMain linked separately. This is a universal solution which works with all versions of Visual Fortran prior to 14.0 and works equally well with 3rd party compilers such as Lahey/Fujitsu Fortran, Absoft Pro Fortran, GNU gfortran and Microsoft PowerStation (two of which have compatible VS2012 integrations). The requirement for special action in IVF 14.0 is inconsistent and unjustified.

Look at this another way. You are selling a product called Intel "Visual" Fortran, but your compiler now actively creates main programs which cannot be used to create Windows GUI (i.e. visual) programs, as its default action! Isn't that just a tad embarassing?

Having to tell users to use a new switch to build programs that built perfectly with Visual Fortran for the last 16+ years is something of a tech support nightmare. It will generate plenty of needless repetitive tech support traffic for us, here at ISS, that's for sure.

Please reconsider your current solution to the VS2012 console app problem. You should move the solution to the right place (i.e. the link step). Remember, not everybody builds their applications in Visual Studio. We don't need (non-)solutions like this foisted on those who are happily building in environments such as the command prompt and third party IDEs.

Can you show me an example of what goes wrong with this change? So far, my experiments haven't shown a deleterious effect - the most I see is that if I build a console app with /winapp, it builds and runs whereas in older versions one would get a link error about a missing WinMain.

I think there may be a better way to solve the problem and will discuss this with Lorri and the other developers.

Steve Intel Developer Support

I always wait a week or so before installing updates to flush out any strange issues! Obviously in this crazy multi-platform, multi-version, multi-personality world, updates can't be perfect so this forum it great! I use Winteracter (and love it!) for GUI and would have gone nuts seeing a console window pop up due to update. Thank you Winteracter for alerting us to that issue! Steve & Lorri, thanks for the quick response!

Quote:

Steve Lionel (Intel) wrote:

Can you show me an example of what goes wrong with this change? So far, my experiments haven't shown a deleterious effect - the most I see is that if I build a console app with /winapp, it builds and runs whereas in older versions one would get a link error about a missing WinMain.

I think there may be a better way to solve the problem and will discuss this with Lorri and the other developers.

The steps to reproduce the fault are simple. Create a trivial main program which will take a few seconds to execute, to give you time to see the unwanted window. Here's a suitable example:

a = 1.0
b = 2.0
do i = 1,HUGE(I)
c = a + b + c
end do
open(20,file='output.txt',status='unknown')
write(20,*) c
close(20)
end

At a command prompt, using the 14.0 compiler, compile and link this using:

ifort /c prog.f90
link prog.obj -subsystem:windows

Hex dump the resulting prog.obj to see the unwanted embedded /SUBSYSTEM:CONSOLE switch. To see the unwanted console window in action, run the resulting executable from Windows Explorer (i.e. not from the command prompt where the exe was built, since that console window will be used as the associated console). The result is clearly a console program, not a "windows" program.

Obviously the above is just to demonstrate the effect. In a real world application a WinMain would be linked, which in turn calls main() to kick off the Fortran main program. However, that's useless in the above context with 14.0, since that function never gets called. As indicated earlier, this is a mechanism which works perfectly well with a whole raft of compilers, not just Visual Fortran. IVF 14.0 is now out of step not just with every previous version of VF, but with most other Windows Fortran compilers too.

We've already had one customer roll back to IVF 13.1 because of this issue. Telling customers to use the undocumented -switch:fe_no_subsystem switch to work round this compiler fault is less than satisfactory. Customers will inevitably (a) mistrust it because of its undocumented status (b) not be aware of it (c) apply it in the wrong place (the last of these has already happened). Please undo this ill-considered change.

Thanks for the illustration. To see the problem requires that one use "link" rather than "ifort" to do the linking.

The problem we were trying to fix was that "link" in VS2012 doesn't apply any /subsystem option by default - you have to specify it explicitly. I agree that the solution chosen was, in retrospect, not the best option. The directive is added only for main programs. One would think that our QuickWin, similar in some ways to Winteracter, would see the same problem but the compiler omits the directive when /libs:qwin is specified.

I'm going to try to convince the developers to back out this change - the correct solutionm in my view, is to have the user specify /subsystem when using link directly. But you'll have a similar issue there in that users of VS2012 will get:

LINK : fatal error LNK1561: entry point must be defined

if no /subsystem was specified. My recommendation for Winteracter users is to either use ifort to link or to explicitly specify /subsystem:windows when linking. This won't help right away, since the directive will override it, but you'll see this issue even with 13.1 when VS2012 is used for the command line environment.

Steve Intel Developer Support

Thanks for your comments Steve.

The problem with using ifort to link is much the same as the -switch:fe_no_subsystem, namely that it requires unnecessary changes for significant numbers of users spread across an even larger number of projects (since each user is likely to have multiple projects).

Specifying subsystem at link time is clearly the right solution. Indeed, it should be the only solution, since it is after all a linker switch. However, our linking instructions have always specified that the -subsystem:windows switch is required. The whole point here is that having /SUBSYSTEM:CONSOLE embedded in the main program object overrides that link-time choice, thus rendering such advice useless (without the use of the unwelcome undocumented -switch:fe_no_subsystem compile time switch to disable action that should never have been taken in the first place).

Yes the LNK 1561 eror will occur if /subsystem:windows is not specified. However, given that we've been telling all our customers to use this linker switch for the last 16 years, with all versions of Visual Fortran (plus several others, as indicated previously), this isn't an issue. If users fail to follow documented methods of compiling and linking, then it is reasonable to expect that errors may occur. That's nothing new and should require no new action on either your part or ours.

It's also worth saying that our development environment (WiDE), which provides logically similar functionality to VS, is designed to use LINK (or XILINK) to perform linking, rather than the ifort front end. LINK/XILINK are, after all linkers, so it's not at all unreasonable to expect to use them to link programs. This would require program changes which really ought to be totally unnecessary.

The bottom line here is that specification of subsystem is a link time choice. When the compiler performs both compilation and linkage (as in the case where /c is not specified to the front end) then its perfectly reasonable for the front end to default to a specific subsystem (i.e. console). That of course is what it has always done (like other Windows Fortran compilers). However, when compilation and linking are performed separately, the front end has absolutely no business second guessing the intent of the programmer, by enforcing an arbitrary choice of link time switch at compile time. If the user chooses to compile and link in separate steps, it's almost certain that he/she wants full control over the link step. In that case the user can reasonably expect to have their link switches (e.g. /subsystem) honoured at link time, rather than having the wrong switches foisted on them by the compiler front end author.

I agree with you and I think the developers have agreed to back out this change. I'll keep you posted.

Steve Intel Developer Support

Indeed, the directive will be gone as of Update 1, planned for mid-late October.

Steve Intel Developer Support

The 14.0.1.139 update does indeed fix this issue. Thanks Steve.

Thanks for bringing it to our attention.

Steve Intel Developer Support

Faça login para deixar um comentário.