definition of dllimport function not allowed

[DarkWarriorBOW]

Can anyone enlighten me on why I am getting this ?

 

Compiling...

cal3d_wrapper.cpp

H:\Development\EL\elc\cal3d_wrapper.cpp(6) : error C2491: 'CalModel_GetAttachedMesh' : definition of dllimport function not allowed

H:\Development\EL\elc\cal3d_wrapper.cpp(11) : error C2491: 'CalCoreSkeleton_Scale' : definition of dllimport function not allowed

H:\Development\EL\elc\cal3d_wrapper.cpp(17) : error C2491: 'CalMixer_ExecuteAction_Stop' : definition of dllimport function not allowed

H:\Development\EL\elc\cal3d_wrapper.cpp(22) : error C2491: 'CalMixer_RemoveAction' : definition of dllimport function not allowed

H:\Development\EL\elc\cal3d_wrapper.cpp(27) : error C2491: 'CalCoreAnimation_Scale' : definition of dllimport function not allowed

H:\Development\EL\elc\cal3d_wrapper.cpp(32) : error C2491: 'CalCoreMesh_Scale' : definition of dllimport function not allowed

Error executing cl.exe.

 

many thanks in advance.

[ttlanhil]

sure can, and I even know how to fix it! (yes, I ran into the same problem)

Cal3D wrapper file, which is included in ELC, has two options when compiled in MSVC, either to become a library, or to use a library.

to fix it, add CAL3D_WRAPPER_EXPORTS to preprocessor line of cal3d_wrapper.cpp (right-click the file and go into its options)

do NOT add that to the entire project, or else the rest of the files using cal3d_wrapper.h (the header) will become broken

 

you could also add a #define line to the start of cal3d_wrapper.cpp, but 1) that's modifying source and not just build config, 2) if you watch what files are changed from CVS, the fewer the better, and 3) if the top of the file changes in CVS, you'll have to manually update

[Zep]

Maybe someone can add a #ifndef for that compiler?

Edited October 31, 2005 by Zep

[DarkWarriorBOW]

sure can, and I even know how to fix it! (yes, I ran into the same problem)

Cal3D wrapper file, which is included in ELC, has two options when compiled in MSVC, either to become a library, or to use a library.

to fix it, add CAL3D_WRAPPER_EXPORTS to preprocessor line of cal3d_wrapper.cpp (right-click the file and go into its options)

do NOT add that to the entire project, or else the rest of the files using cal3d_wrapper.h (the header) will become broken

 

you could also add a #define line to the start of cal3d_wrapper.cpp, but 1) that's modifying source and not just build config, 2) if you watch what files are changed from CVS, the fewer the better, and 3) if the top of the file changes in CVS, you'll have to manually update

215431[/snapback]

 

cool, that worked, thanks..

 

Now i am left with some undefined external symbols on a handful of files, but i'll try and figure that out on my own first.

 

so much for documentation...

[Lhibou]

with the option CAL3D.... on the specified file, I have after that a .lib and a .exp files. IS it correct?

 

I always have this warning:

cal.h(10) : warning C4273: 'CalCoreAnimation_Scale' : inconsistent dll linkage. dllexport assumed.

 

I have other warning of this style in cal.h.

 

Is there another thing to do?

[ttlanhil]

with the option CAL3D.... on the specified file, I have after that a .lib and a .exp files. IS it correct?

 

I always have this warning:

cal.h(10) : warning C4273: 'CalCoreAnimation_Scale' : inconsistent dll linkage. dllexport assumed.

 

I have other warning of this style in cal.h.

 

Is there another thing to do?

215504[/snapback]

dunno how to fix this one (yeah, 5 warnings per file that includes(or includes a file that includes, etc) cal3d_wrapper.h ... not fun). i've played around with it a bit a while ago, but ELC is my experience with C/C++, so I could easily miss something simple

I ended up adding number 4273 to the 'ignore warnings' line in project config (originally I added a #pragma ignore() or whatever it is of the number in the file itself, but I prefer to have cvs-clean files where possible)

just remember to set it for all configs (such as `release` and `debug`) ^_^

[DarkWarriorBOW]

Ok.. one other problem that I can't seem to fix on my own.

 

Anyone know how to fix this one ? I am quite sure its easy, i just can't figure it out.

 

Linking...
  Creating library C:\Eternal Lands\EternalLands.lib and object C:\Eternal Lands\EternalLands.exp
trade.obj : error LNK2001: unresolved external symbol _get_items_texture
bags.obj : error LNK2001: unresolved external symbol _get_items_texture
hud.obj : error LNK2001: unresolved external symbol _get_items_texture
manufacture.obj : error LNK2001: unresolved external symbol _get_items_texture
storage.obj : error LNK2001: unresolved external symbol _get_items_texture
C:\Eternal Lands\EternalLands.exe : fatal error LNK1120: 1 unresolved externals
Error executing link.exe.

EternalLands.exe - 6 error(s), 273 warning(s)

 

By the way, what's with the thread system of this messageboard.

It totally sucks i hate it.

Is the old system still available ?

[Lhibou]

seem's that you have a problem with the __inline__.

 

I added in global.h under the ifdef _MSC_VER a #define __inline__ __inline

 

Thx. Ttl for the info.

Edited October 31, 2005 by Lhibou

[DarkWarriorBOW]

seem's taht you don't have items.c(h) in your project.

 

Thx. Ttl for the info.

215565[/snapback]

 

I confirmed that and items.c(h) is in the project and is getting compiled.

 

has to be something else then.

[Lhibou]

seem's taht you don't have items.c(h) in your project.

 

Thx. Ttl for the info.

215565[/snapback]

 

I confirmed that and items.c(h) is in the project and is getting compiled.

 

has to be something else then.

215566[/snapback]

 

Modified my post, because if items.c was missing, there must be more link errors.

[DarkWarriorBOW]

Hmm sorry, but that doesnt seem to do anything for me.

 

I still get the same errors.

 

Somehow those functions are not available to the project or something. Like I am forgetting to include some kind of package.

[Lhibou]

Hmm sorry, but that doesnt seem to do anything for me.

 

I still get the same errors.

 

Somehow those functions are not available to the project or something. Like I am forgetting to include some kind of package.

215576[/snapback]

 

It's normally the first function in items.c. You can try without the __inline__ instruction before the GLuint.

[DarkWarriorBOW]

Seems you were right. That indeed fixed the problem and now it finally compiles. YAY.

 

And once I figure out why my own build is as slow as a snale in hybernation, I am going to sit back and pat myself on the shoulder for not having such an incredible disorganized and undocumenting development team under my command LOL.

 

Thanks for all your help Lhibou and ttan.

[Strings]

It's normally the first function in items.c. You can try without the __inline__ instruction before the GLuint.

215599[/snapback]

 

OK, here is the reason and answer to your problem.

It's to do with how MSVC handles inline code.

 

A function marked as inline is "inlined" as part of the C compilation phase when the intermediate compilation file (.obj) is created.

Therefore if another c file, creates another (.obj) it cannot be cross referenced.

Therefore all inline functions must be visible to every object compilation.

 

This differs from most other compilers where the inline operation is either done during the linking phase, or where the inline is considered a weak constraint, and is removed if the function is refered to in another object file.

 

So in conclusion, inline function code must appear in header files for it to work in MSVC. This allows every object compilation to inline the function during the C compilation phase.

 

If I haven't managed to make myself clear then just say and I will have another go at explaining it.

 

Still the "rule" is that an inline function should only be defined in a c file if it is only referenced in that file. If a function in one c file is referenced by another c file, it should not be inlined in MSVC.

 

Hope I have managed to shed a bit of light.

 

Strings

[Learner]

It's normally the first function in items.c. You can try without the __inline__ instruction before the GLuint.

215599[/snapback]

 

OK, here is the reason and answer to your problem.

It's to do with how MSVC handles inline code.

 

A function marked as inline is "inlined" as part of the C compilation phase when the intermediate compilation file (.obj) is created.

Therefore if another c file, creates another (.obj) it cannot be cross referenced.

Therefore all inline functions must be visible to every object compilation.

 

This differs from most other compilers where the inline operation is either done during the linking phase, or where the inline is considered a weak constraint, and is removed if the function is refered to in another object file.

 

So in conclusion, inline function code must appear in header files for it to work in MSVC. This allows every object compilation to inline the function during the C compilation phase.

 

If I haven't managed to make myself clear then just say and I will have another go at explaining it.

 

Still the "rule" is that an inline function should only be defined in a c file if it is only referenced in that file. If a function in one c file is referenced by another c file, it should not be inlined in MSVC.

 

Hope I have managed to shed a bit of light.

 

Strings

Or put it in the .h as a #define