symbols multiply defined

[LRaim]

I have already opened this topic with premier support but what I need is a urgent work-around.

These symbol are linked to temporary variables outside my control.

So I cannot go ahead with my development activity.

==========================================================================

1>------ Build started: Project: Xpsim22, Configuration: Release Win32 ------
1>Linking...
1>V1ITHERD.obj : error LNK2005: .T174_ already defined in V1IBEG00.obj
1>Release\Xpsim22.exe : fatal error LNK1169: one or more multiply defined symbols found

1>

1>Build log written to "file://C:\YF\XPSIM22\Xpsim20\Release\BuildLog.htm"

1>Xpsim22 - 2 error(s), 0 warning(s)

========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

================================================================

By browsing the .obj files in hex format one can see the symbols in two different files .

A rebuild-all has not solved the problem that appears sometime  in the debug build and sometimes in the release one.

[jimdempseyatthecove]

You might find http://stackoverflow.com/questions/6940384/how-to-deal-with-symbol-collisions-between-statically-linked-libraries useful.

The writer of those object files should not have made temporary variables visible. This said, if you are unable to change this, then consider using objcopy and its prefix-symbols option.

*** Note, this will not resolve the situation where both symbols are to share the same memory. ***

Jim Dempsey

[LRaim]

I usually try to be as concise as possible so I apologize  to be not always clear.

The symbols come from two fortran source files and are generated by the Intel compiler.

It is difficult to understand why a compiler generates 'external' symbols for temporary internal variables or structure. 

If the symbols are generated in a random way the algorithm is not able to assure their uniqueness.

[jimdempseyatthecove]

I haven't seen your particular situation, there is only one thing that I can think of at this time, it is a long shot as to what your problem may be.

The Linker involved is MS's linker. This linker permits multiple, duplicate, code and/or data sections of the same name. *** duplicate being the definitive word. This is a requirement for C++ precompiled headers. Yes, you are Fortran...

In Fortran (IVF at least), on can declare named COMMON, and in particular Thread Private named common blocks. The correct practice is to make the declaration in only one place, preferably in a module, but it can be in a Fortran include file (not recommended). If on the other hand, you make multiple declarations of this named common and/or thread private section .AND. all such places where you make these declarations are not identical, then you will have multiple declarations that are not duplicate, and thus get rejected by the linker.

Note, you may be experiencing a different issue, but the above is something you can look at now.

Jim Dempsey

[Steven_L_Intel1]

I looked at your Premier Support issue. You didn't provide sources to reproduce the problem and are using the 15.0.1 compiler. I looked to see if this was a known problem that we may have fixed or are investigating, but my searches didn't turn up anything. 

The support engineer reasonably suggested that you try a more recent compiler and see if it resolves the problem, since you didn't provide what we would need to investigate further. 

[LRaim]

Dear Steve,

thanks for your kind reply but I have to point out a few things. 
I am moving the developer environment to a new PC and so I will use an updated compiler version possibly next week.

When my simulation software fails and a user asks something I usually try to give an answer and first of all to suggest a possible work around.

Meanwhile, since symbols like " .T174_ " are not defined in the two source codes I have to assume that they are generated by the Fortran compiler  and I asked an answer about this point. 

So I would expect from premier support an answer of the kind "yes, are generated by the compiler" or the contrary.
If these symbols are generated by the compiler this is probably linked to a general sw architectural choice in generating the assembly of some Fortran constructs. 

Compiler developers should be able to give such an answer immediately.   Moreover they should know whether this has been changed in the new compiler versions or not.

[Steven_L_Intel1]

Yes, that symbol is generated by the compiler. I thought you already understood that. These symbols are not supposed to be global, though, and should never cause linker errors. The compiler creates many of these symbols for local temporary variables.

If you can provide us with a test case we can investigate further. There's little we can do with a generic description of a problem.

[LRaim]

Steve,

I would like to avoid playing with .obj files though many years ago I wrote a "delinker" (IBM, MVS 370 using Fortran H ext) to extract obj files from .exe files to finally relink them on a PC AT 370 running VM 370.

However after doing some tests and browsing the V1IBEG00.obj one can find:

• the symbol .T174_ is defined between the .data and  .bss section (release build only). 
• other similar symbol (.T214_, .T210_ and .T206_) are defined after/in  the .bss section.

The only apparent common feature in the V1ITHERD.for and V1IBEG00.for sources is the use of SAVE and ENTRY statements, but V1ITHERD includes many subroutine whereas only one is defined in V1IBEG00.

The application is built with over 600 source files so how the symbols .Txyz are generated has some weakness.

An explanation of this point by Intel would be interesting. Can I safely edit and change the symbol in the .obj files ?

I will send today a copy of the source and obj files to the premier support.

Regards 

[Steven_L_Intel1]

I do not recommend editing the object files. If you can provide a source that, when compiled, makes these temporary symbols global, we can fix it, or tell you what you need to change. We probably need only one such source.

Let me ask this - are you INCLUDEing a file that contains both COMMON block definitions and initializations of variables in a COMMON block?

[Steven_L_Intel1]

I got the sources you provided and am investigating. Thanks.

[LRaim]

Steve,

for your information:

The same source file V1IBEG00.FOR (the same file not a copy) is used in another project.

In this case the symbol generated in release mode is .T176_

[Steven_L_Intel1]

Yes, I can see the problem now. It is still present in a current compiler.

It seems related to your declarations of LSKEYV and LBKEYV as EQUIVALENCED character variables. The compiler is improperly making these symbols global. There are other symbols I don't think should be global, but they all have names that won't conflict with other sources.

I will raise the issue to the developers. Here's a workaround.

You have:

      CHARACTER*8  ISKEY /'UTHDSC00'/
      CHARACTER*1 LSKEYV(8)
      EQUIVALENCE  (ISKEY,LSKEYV(1))
!
!
      CHARACTER*8  IBKEY /'UTHDBC00'/
      CHARACTER*1 LBKEYV(8)
      EQUIVALENCE  (IBKEY,LBKEYV(1))

Remove the initialization on ISKEY and IBKEY. Then at the first executable line (where you have the PROCESSING comment) add assignments to these variables, like so:

      ISKEY = 'UTHDSC00'
      IBKEY = 'UTHDBC00'

This removes the problem.  You'll need to do this in each source that has a similar issue.

[Steven_L_Intel1]

This problem occurs when you have a local initialized variable that is equivalenced and you use it in a contained procedure. This has been escaated as issue DPD200408495.

[Steven_L_Intel1]

I expect this bug to be fixed in Update 2 to Parallel Studio XE 2017.

[Kevin_D_Intel]

Development confirmed the fix will be in our PSXE 2017 Update 2 release next month.

[LRaim]

Many thanks for previous support and update information.

Luigi R.