- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- « Previous
- Next »
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
tks.
And having one routine exported thus automatically exports all? From all source files or just the specified one?
K
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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".
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Under Linker > Command Line > Additional Options, type:
/ignore:4049
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- « Previous
- Next »