Silverfrost Forums

Welcome to our forums

salflibc.pdb not loaded

10 Dec 2017 2:35 #20963

Hello, I am using FTN95 8.10. When I compile in debug mode, no issue. But when I am making a Release build, it says 'salflibc.pdb' not loaded, as it expects the symbol manager to be reinitialised with this salflibc.pdb. But this pdb symbol manager file is not available at the silverfrost installable folder. Not sure, if this topic was discussed already in our Forum here. Please help, is it not included in 8.10 or how can I get this pdb to make the release build. Appreciate your quick response. Thank you

10 Dec 2017 2:40 #20964

Few more details to help you with. I am using Visual studio 2015 Community, and my system include .NET framework 4.5.x, 4.6.x already Thank you

11 Dec 2017 7:58 #20975

There is no salflibc.pdb, essentially because salflibc.dll is not built (by Silverfrost) using VS.

I don't know why it is reported as missing. There must be something wrong with your VS project settings.

12 Dec 2017 4:50 #20978

Hi Paul and John Thank you very much for the reply. I agree that there is no Salflibc.pdb in our FTN95 installed folders.

The VS keeps the symbol setting 'None' only in the Debug/symbol, by default. However, the 'Salflibc.pdb not loaded' error page says, to identify the PDB in FTN95 directory and select it for loading.

But I remember the trick which I did earlier, as you said, I copied the salflibc.dll file at the Project folder, then this error was not shown while making build/release.

Not sure, what project settings in VS 2015 causing this issue. Pls. suggest

Thank you

12 Dec 2017 7:17 #20979

Moorthy

I don't know how to fix this. If you have created the project using one of the given FTN95 options then the FTN95 VS plug-in will be used and salflibc.dll will be scanned automatically by SLINK at link time. SLINK will normally find salflibc.dll on the global PATH environment variable.

12 Dec 2017 6:04 #20980

Paul

Thanks for your views. The global PATH was also already defined correctly. The project is created in FTN95 in VS using default option. So FTN95 VS plug-in should automatically scan for salflibc.dll in the PATH. Probably, this could be the issue with VS settings inside the editor on PATH. Let me check it again and report back here.

But is this issue reported earlier in VS 2013 till Feb 2017? It helps to know the strategy what was adopted in VS 2013, to overcome it in VS 2015.

12 Dec 2017 6:05 #20981

Paul

Thanks for your views. The global PATH was also already defined correctly. The project is created in FTN95 in VS using default option. So FTN95 VS plug-in should automatically scan for salflibc.dll in the PATH. Probably, this could be the issue with VS settings inside the editor on PATH. Let me check it again and report back here.

But is this issue reported earlier in VS 2013 till Feb 2017? It helps to know the strategy what was adopted in VS 2013, to overcome it in VS 2015.

13 Dec 2017 6:22 #20982

Hi John, Thanks. Yes. This is a good workaround. I compiled for release and debug from same workspace code. Your advice helps to avoid the error.

But, let me ask a scenario wherein many f95 files and references included in a project workspace. It may not be feasible to extract it in a separate project workspace for 'release' alone. Simple option to switch between Debug and Release mode, in the same project workspace is essentially comfortable and feasible on longer run, which is what our development community follows.

Do you suggest any other alternatives. Seeking Paul's views as well.

13 Dec 2017 7:56 #20983

Moorthy

I don't understand your question.

Both VS and Plato have project options 'checkmate', 'debug' and 'release'. You select one of these before building a project. They are respectively equivalent to using a) /CHECKMATE, b) /DEBUG and c) neither of these, on the FTN95 command line.

The object code produced by FTN95 differs for each of these 'configurations' and VS/Plato make things easier for you by automatically generating subfolders for the various configurations and platforms (Win32, .NET and x64). This is to avoid unnecessary recompilation when editing and changing from one configuration or platform to another.

It is possible to change the compiler options for selected files and make them different from those of the current configuration (and maybe this is what you have done) but I can't see any advantage to doing this in this context. Both /CHECKMATE and /DEBUG are designed to be used when developing and testing code, after which you can use 'release' for production runs and/or for release to end users.

13 Dec 2017 9:07 #20984

Paul Thank you very much for your reply. I am also following the same what you indicated.

It is possible to change the compiler options for selected files and make them different from those of the current configuration (and maybe this is what you have done)

Just to clarify more to what you quoted. In this, I am not changing the compiler options for the selected file in both (Debug/Release) configuration, as I am using same files in both configurations. But how that 'salflibc.pdb not found' error, has occurred, which I am still unable to identify.

Perhaps, your views and John's Views are the same, which I should strictly follow hence forth.

Thank you

@John-Silver: Thank you once again.

Please login to reply.