Forum Jump

Select Group :
Select Forum :
Sorted By :
Sort Order :
From The :
 
Thread Tools  Search this thread 
cvnravi
Total Points:
235
Status Points:
185
Green Belt
July 3, 2009 12:00 AM PDT
linking errors in C language from fortran library
Hi,

I am porting the application with old fortran compiler and old visual studio(VC5) to new fortran compiler 11 and visual studio 2005. Application contains both 'C' and fortran code. I am compiling the fortran code and creating library called server_lib.lib(library is createing with some warnings) and linking to the 'C' code. while linking application is giving some below linking errors.

2>Linking...
2>server_lib.lib(Preparx.obj) : error LNK2005: _SERVERSTUFF already defined in server_lib.lib(Athena7.obj)
2>server_lib.lib(Query.obj) : error LNK2005: _SERVERSTUFF already defined in server_lib.lib(Athena7.obj)
2>server_lib.lib(Utm.obj) : error LNK2005: _SERVERSTUFF already defined in server_lib.lib(Athena7.obj)
2>server_lib.lib(Runvhf.obj) : error LNK2005: _SERVERSTUFF already defined in server_lib.lib(Athena7.obj)
2>server_lib.lib(PFLTPV.obj) : error LNK2005: _SERVERSTUFF already defined in server_lib.lib(Athena7.obj)
2>server_lib.lib(Qdesic.obj) : error LNK2005: _SERVERSTUFF already defined in server_lib.lib(Athena7.obj)
2>server_lib.lib(Headach.obj) : error LNK2005: _SERVERSTUFF already defined in server_lib.lib(Athena7.obj)
2>server_lib.lib(Plotky.obj) : error LNK2005: _SERVERSTUFF already defined in server_lib.lib(Athena7.obj)
2>server_lib.lib(Terrain.obj) : error LNK2005: _SERVERSTUFF already defined in server_lib.lib(Athena7.obj)
2>server_lib.lib(Morpho.obj) : error LNK2005: _SERVERSTUFF already defined in server_lib.lib(Athena7.obj)
2>server_lib.lib(Diflos.obj) : error LNK2005: _SERVERSTUFF already defined in server_lib.lib(Athena7.obj)
2>server_lib.lib(Micro.obj) : error LNK2005: _SERVERSTUFF already defined in server_lib.lib(Athena7.obj)
2>server_lib.lib(OpenGL_F.obj) : error LNK2005: _SERVERSTUFF already defined in server_lib.lib(Athena7.obj)
2>server_lib.lib(Violet.obj) : error LNK2005: _SERVERSTUFF already defined in server_lib.lib(Athena7.obj)
2>server_lib.lib(Fieldp.obj) : error LNK2005: _SERVERSTUFF already defined in server_lib.lib(Athena7.obj)
2>server_lib.lib(Step.obj) : error LNK2005: _SERVERSTUFF already defined in server_lib.lib(Athena7.obj)
2>server_lib.lib(White.obj) : error LNK2005: _SERVERSTUFF already defined in server_lib.lib(Athena7.obj)
2>.\Debug/Server.exe : fatal error LNK1169: one or more multiply defined symbols found


above "serverstuff" is defined in server.for file only and this server.for is included in all above files like Athena7.for,White.fort,Step.for etc. Please find the below code block from server.for file.

INTEGER iErrPipe !error code for pipe i/o
INTEGER clientIndex !index into client list
CHARACTER*136 Buffer(17) !buffer for pipe i/o
CHARACTER dBuffer(2313) !buffer for pipe i/o
EQUIVALENCE(dBuffer,Buffer)
COMMON/serverstuff/clientIndex,dBuffer

DATA dBuffer(2313)/0/


Why the above code is giving redecleration error? How it worked with previous fortran compiler? When I am commenting the "COMMON/serverstuff/clientIndex,dBuffer" line then it's linking perfectly, but the application is crashed..

Please give me any idea as I don't know about fortran language.
Jugoslav Dujic
Total Points:
6,542
Status Points:
6,542
Black Belt
July 3, 2009 12:59 AM PDT
Rate
 
#1
Quoting - cvnravi
Hi,

I am porting the application with old fortran compiler and old visual studio(VC5) to new fortran compiler 11 and visual studio 2005. Application contains both 'C' and fortran code. I am compiling the fortran code and creating library called server_lib.lib(library is createing with some warnings) and linking to the 'C' code. while linking application is giving some below linking errors.

2>Linking...
2>server_lib.lib(Preparx.obj) : error LNK2005: _SERVERSTUFF already defined in server_lib.lib(Athena7.obj)

above "serverstuff" is defined in server.for file only and this server.for is included in all above files like Athena7.for,White.fort,Step.for etc.

It sounds as if you did redeclaration by include, like:

File Preparx.for
==========================
INCLUDE "Serverstuff.for"
SUBROUTINE Preparx()
...
END
INCLUDE statement basically works as a copy/paste macro, and in effect you define Subroutine ServerStuff in every of your sources. I don't think that C/Fortran has anything to do with that error.

I don't know how it compiled with another compiler, but that's not the way to do things in Fortran. Actually, that's not how to do things in C either -- C include files should contain just function prototypes, not their bodies.

If my analysis is correct, you should get rid of those INCLUDE lines. Have in mind, though, that I haven't seen your actual code and that I might easily have misdiagnosed the situation.

--------
Jugoslav
www.xeffort.com
cvnravi
Total Points:
235
Status Points:
185
Green Belt
July 3, 2009 1:38 AM PDT
Rate
 
#2 Reply to #1
Quoting - Jugoslav Dujic

It sounds as if you did redeclaration by include, like:

File Preparx.for
==========================
INCLUDE "Serverstuff.for"
SUBROUTINE Preparx()
...
END
INCLUDE statement basically works as a copy/paste macro, and in effect you define Subroutine ServerStuff in every of your sources. I don't think that C/Fortran has anything to do with that error.

I don't know how it compiled with another compiler, but that's not the way to do things in Fortran. Actually, that's not how to do things in C either -- C include files should contain just function prototypes, not their bodies.

If my analysis is correct, you should get rid of those INCLUDE lines. Have in mind, though, that I haven't seen your actual code and that I might easily have misdiagnosed the situation.


Hi Thanks for your reply.. Part of your investigation is correct.. But serverstuff is a COMMON data which is included in  "server.for" file. Check the below code from server.for file.

INTEGER clientIndex !index into client list
CHARACTER*136 Buffer(17) !buffer for pipe i/o
CHARACTER dBuffer(2313) !buffer for pipe i/o
EQUIVALENCE(dBuffer,Buffer)
COMMON/serverstuff/clientIndex,dBuffer

DATA dBuffer(2313)/0/


As you said, server.for is included in some of the other files, though it is a global variable, serverstuff is giving redecleration problem when linking libraries. How can i split that COMMON data in such a way that, it should include in all required files and should not give redecleration error??

clientindex and dBuffer are using in C language piping calls(PipeRead and PipeWrite) which are called from fortran.

Thanks in advance..
Les Neilson
Total Points:
5,676
Status Points:
5,176
Brown Belt
July 3, 2009 3:44 AM PDT
Rate
 
#3 Reply to #2
Quoting - cvnravi


Hi Thanks for your reply.. Part of your investigation is correct.. But serverstuff is a COMMON data which is included in  "server.for" file. Check the below code from server.for file.

INTEGER clientIndex !index into client list
CHARACTER*136 Buffer(17) !buffer for pipe i/o
CHARACTER dBuffer(2313) !buffer for pipe i/o
EQUIVALENCE(dBuffer,Buffer)
COMMON/serverstuff/clientIndex,dBuffer

DATA dBuffer(2313)/0/


As you said, server.for is included in some of the other files, though it is a global variable, serverstuff is giving redecleration problem when linking libraries. How can i split that COMMON data in such a way that, it should include in all required files and should not give redecleration error??

clientindex and dBuffer are using in C language piping calls(PipeRead and PipeWrite) which are called from fortran.

Thanks in advance..

If server.for is only to be used as an include file maybe you could try renaming it to server.inc (or something similar - some people prefer server.fi for example). Change all of your "include server.for" to "include server.inc"
{ I don't see how from the code you have shown, but it sounds like server.for is being compiled as a function/subroutine in its own right, every time - hence the multiple declarations }

A better option would be to make server.for a MODULE (instead of common) which you then USE in those routines that need that data.

module serverstuff
INTEGER clientIndex !index into client list
CHARACTER*136 Buffer(17) !buffer for pipe i/o
CHARACTER dBuffer(2313) !buffer for pipe i/o
EQUIVALENCE(dBuffer,Buffer)
...
end module serverstuff

Les

Les

Steve Lionel (Intel)
Total Points:
112,121
Status Points:
112,121
Black Belt
July 3, 2009 6:46 AM PDT
Rate
 
#4
This has never worked on Windows - it might have worked on some other platforms.

The problem is that you DATA initialize a variable in the COMMON each time you declare the COMMON - that is, in the INCLUDE file.  This is not legal and most linkers, including Microsoft's, don't like it.

The solution is to move the DATA initialiization to a BLOCK DATA module and then reference the name of the BLOCK DATA in an EXTERNAL declaration in the INCLUDE to make sure it gets pulled in.
cvnravi
Total Points:
235
Status Points:
185
Green Belt
July 3, 2009 8:04 AM PDT
Rate
 
#5 Reply to #3
Hi les,

It works for me.. Thanks alot..

Quoting - Les Neilson

If server.for is only to be used as an include file maybe you could try renaming it to server.inc (or something similar - some people prefer server.fi for example). Change all of your "include server.for" to "include server.inc"
{ I don't see how from the code you have shown, but it sounds like server.for is being compiled as a function/subroutine in its own right, every time - hence the multiple declarations }

A better option would be to make server.for a MODULE (instead of common) which you then USE in those routines that need that data.

module serverstuff
INTEGER clientIndex !index into client list
CHARACTER*136 Buffer(17) !buffer for pipe i/o
CHARACTER dBuffer(2313) !buffer for pipe i/o
EQUIVALENCE(dBuffer,Buffer)
...
end module serverstuff

Les

Les


Intel Software Network Forums Statistics

8285 users have contributed to 31229 threads and 99106 posts to date.
In the past 24 hours, we have 13 new thread(s) 50 new posts(s), and 68 new user(s).

In the past 3 days, the most popular thread for everyone has been comparison cilk++, openmp, pthreads first results The most posts were made to comparison cilk++, openmp, pthreads first results The post with the most views is Very amusing...  Escalated as

Please welcome our newest member tvinni