Porting from Silverfrost FTN95 - anyone been here before?

[Kenny_T_1]

Hi,

I'm evaluating IVF with a view to "changing horses" from Silverfrost's FTN95 compiler.  I've tried compiling a source file with module definitions but get "loads of errors" that I don't know how to fix.  Has anyone trod this path before and is prepared to get me kick-started by "fixing" the attached source file?

TIA

K

[Kenny_T_1]

tks.

And having one routine exported thus automatically exports all?  From all source files or just the specified one?

K

[Steven_L_Intel1]

No - one routine exported exports that one. You need to add the directive (with the appropriate routine name) in each routine to be exported.

An alternative is to use a .DEF file that is input to the linker. If you have lots of routines, and are not exporting any data, this may be preferable for you.

See http://msdn.microsoft.com/en-us/library/d91k01sh.aspx for documentation of .DEF files. You can leave off the "ordinal".

[Kenny_T_1]

OK, thanks (I think I've got my work cut out!)

Another question:

I've got my "modules" DLL and two other DLLs (app_main and replib) that each "USE" structures and call routines that are defined in the modules.  When i link the first DLL (replib) it has undefined entries from the modules, so i add the modules.lib to the dependents list and all is apparently good.  When i come to link my second DLL (app_main), i again get undefined entries from the modules, so i again add the modules.lib to the dependents list for the second DLL but i now get:

error LNK2005: _ZW_MAIN already defined in replib.lib(replib.dll)    modules.lib(ZW_MAIN.obj)    

What's the trick?

K

[Kenny_T_1]

Kenny T. wrote:

OK, thanks (I think I've got my work cut out!)

Another question:

I've got my "modules" DLL and two other DLLs (app_main and replib) that each "USE" structures and call routines that are defined in the modules.  When i link the first DLL (replib) it has undefined entries from the modules, so i add the modules.lib to the dependents list and all is apparently good.  When i come to link my second DLL (app_main), i again get undefined entries from the modules, so i again add the modules.lib to the dependents list for the second DLL but i now get:

error LNK2005: _ZW_MAIN already defined in replib.lib(replib.dll)    modules.lib(ZW_MAIN.obj)    

What's the trick?

K

does anyone have an answer - or if you need more info, let me know...

K

[Kenny_T_1]

Steve Lionel (Intel) wrote:

The Microsoft linker doesn't have such an option. In each routine, add the line:

!DEC$ ATTRIBUTES DLLEXPORT :: routine-name

where routine-name is the name of the routine.

so...

i've started putting in the !DEC$ ATTRIBUTES DLLEXPORT lines where they were coming up as undefined externals:

(error LNK2019: unresolved external symbol _RU_GETC referenced in function _MAIN__    rep.obj),

but now following a build, i'm getting loads and loads of warnings:

(warning LNK4049: locally defined symbol _RU_GETC imported    pr_eco.obj)

what am i doing wrong?

K

[Steven_L_Intel1]

You can ignore the LNK4049 warnings. They're simply saying that you are importing a symbol that is defined in your own DLL. This will happen if you USE a module that has DLLEXPORTs. The warning can be disabled in the linker properties if it bothes you.

[Kenny_T_1]

Steve Lionel (Intel) wrote:

You can ignore the LNK4049 warnings. They're simply saying that you are importing a symbol that is defined in your own DLL. This will happen if you USE a module that has DLLEXPORTs. The warning can be disabled in the linker properties if it bothes you.

nope, i give in!  Where do i set that?

:)

K

[Steven_L_Intel1]

Under Linker > Command Line > Additional Options, type:

/ignore:4049

[Kenny_T_1]

Steve Lionel (Intel) wrote:

Under Linker > Command Line > Additional Options, type:

/ignore:4049

tks, i'd never have got that from the help!

edit: is there something similar for the compiler to ignore #11077s?

K

[Steven_L_Intel1]

The compiler has a similar mechanism called /Qdiag-disable (Diagnostics > Disable Specific Diagnostics ), but not all diagnostics can be disabled. 11077 is an xilink diagnostic and it will honor the linker /ignore setting (at least it should - in some older releases it didn't.)