Error public symbol defined in both module

Go Up to Clang-enhanced C++ Compilers

Controlling Warning Messages

The option Enable all warnings (on Project > Options > C++ Compiler > Warnings) invokes the compiler with the -Weverything option, which is a superset of -Wall (for all «easy to avoid» constructions).

Warnings may be enabled or suppressed individually, which requires the name of the warning. To show these names, pass -fdiagnostics-show-option to the compiler. Doing so changes a warning like this:

File1.cpp:32:11: warning: unused variable 'foo'

to this:

File1.cpp:32:11: warning: unused variable 'foo' [-Wunused-variable]

You can then use -Wunused-variable to turn on that warning specifically, without enabling others. To disable that warning, replace the leading -W with -Wno-, and use it in combination with an option to enable the desired warning level. For example: -Wall -Wno-unused-variable will enable all easy to avoid warnings except for unused variables.

Common Errors Porting from BCC32

Code ported from BCC32 may exhibit some of these errors (listed alphabetically, ignoring placeholders like ‘x’).

‘x’ does not refer to a value (in template)

Type names that are dependent on the template parameter must be preceded by typename. Without it, for example:

template <class T>
void doSomething() {
  T::member *var;
}

a * intended for pointer declaration will actually be interpreted as multiplication; and if the intended variable already happens to be in scope, this error will occur, trying to multiply a type name (‘member’ in this example), which is not a value.

Missing ‘typename’ prior to dependent type name ‘x’

Type names that are dependent on the template parameter must be preceded by typename. When omitted, some edge cases may generate other errors, but in general the error and solution is clear.

Pasting formed ‘x’, an invalid preprocessing token

Token pasting with the preprocessor’s ## operator must form a single valid token. In many cases, the operator is not necessary in the first place, so simply removing it resolves the issue.

Public symbol ‘x’ defined in both module A and B

For example:

[ilink64 Error] Error: Public symbol 'triplet::sum' defined in both module C:USERSWIN764NODES.O and C:USERSWIN764UNIT1.O

Static data members should be declared in a header, and defined only once in a source file (not the header).

ILINK64 is documented here: Using ILINK32 and ILINK64 on the Command Line.

Use of undeclared identifier ‘x’ (in template)

Due to two-phase name lookup in templates, identifiers found in base classes are not resolved unless qualified with this->

Also, type names that are dependent on the template parameter must be preceded by typename. Without it, for example:

template <class T>
void doSomething() {
  T::member *var;
}

a * intended for pointer declaration will actually be interpreted as multiplication; and unless the intended variable already happens to be in scope, this error will occur, trying to multiply the template-value with the undeclared identifier (‘var’ in this example).

Common Warnings Porting from BCC32

Code ported from BCC32 may exhibit some of these warnings (listed alphabetically), which may be suppressed.

Conversion from string literal to ‘char *’ is deprecated

-Wdeprecated-writable-strings

Assigning a plain char pointer to a literal C-string is discouraged. Make the pointer const (and if appropriate, consider using std::string).

Implicit conversion changes signedness

-Wsign-conversion

BCC32 ignores an assignment from signed to unsigned.
Clang-enhanced C++ compilers do notice such assignments, and emit a warning or error message.

See Also

• Stricter C++ Compilers (Clang-enhanced C++ Compilers)

Errors and Warnings of Clang-enhanced C++ Compilers

Contents

Controlling Warning Messages

The option Enable all warnings (on Project > Options > C++ Compiler > Warnings ) invokes the compiler with the -Weverything option, which is a superset of -Wall (for all «easy to avoid» constructions).

Warnings may be enabled or suppressed individually, which requires the name of the warning. To show these names, pass -fdiagnostics-show-option to the compiler. Doing so changes a warning like this:

You can then use -Wunused-variable to turn on that warning specifically, without enabling others. To disable that warning, replace the leading -W with -Wno- , and use it in combination with an option to enable the desired warning level. For example: -Wall -Wno-unused-variable will enable all easy to avoid warnings except for unused variables.

Common Errors Porting from BCC32

Code ported from BCC32 may exhibit some of these errors (listed alphabetically, ignoring placeholders like ‘x’).

‘x’ does not refer to a value (in template)

Type names that are dependent on the template parameter must be preceded by typename . Without it, for example:

a * intended for pointer declaration will actually be interpreted as multiplication; and if the intended variable already happens to be in scope, this error will occur, trying to multiply a type name (‘member’ in this example), which is not a value.

Missing ‘typename’ prior to dependent type name ‘x’

Type names that are dependent on the template parameter must be preceded by typename . When omitted, some edge cases may generate other errors, but in general the error and solution is clear.

Pasting formed ‘x’, an invalid preprocessing token

Token pasting with the preprocessor’s ## operator must form a single valid token. In many cases, the operator is not necessary in the first place, so simply removing it resolves the issue.

Public symbol ‘x’ defined in both module A and B

Static data members should be declared in a header, and defined only once in a source file (not the header).

Use of undeclared identifier ‘x’ (in template)

Due to two-phase name lookup in templates, identifiers found in base classes are not resolved unless qualified with this->

Also, type names that are dependent on the template parameter must be preceded by typename . Without it, for example:

a * intended for pointer declaration will actually be interpreted as multiplication; and unless the intended variable already happens to be in scope, this error will occur, trying to multiply the template-value with the undeclared identifier (‘var’ in this example).

Common Warnings Porting from BCC32

Code ported from BCC32 may exhibit some of these warnings (listed alphabetically), which may be suppressed.

Conversion from string literal to ‘char *’ is deprecated

Assigning a plain char pointer to a literal C-string is discouraged. Make the pointer const (and if appropriate, consider using std::string ).

Implicit conversion changes signedness

BCC32 ignores an assignment from signed to unsigned. Clang-enhanced C++ compilers do notice such assignments, and emit a warning or error message.

Источник

Technical Details About ILINK32 and ILINK64

For information on using ILINK32 and ILINK64 on the command line, please see the Using ILINK32 and ILINK64 on the Command Line page.

Contents

ILINK32

ILINK32 links object modules (.OBJ files), library modules (.LIB files), and resources to produce executable files (.EXE, .DLL, and .BPL files). ILINK32 creates and maintains a series of linker state files that contain this information. These state files allow subsequent links to be incremental, greatly reducing the total link time. See Linker-State Files and Debug Information File.

Module Definition Files

The module definition file is a text file that provides information to ILINK32 about the contents and system requirements of a Windows application. You can create a module definition file using IMPDEF.EXE, and you can create import libraries from module definition files using IMPLIB.EXE.

If no module definition file is specified, the following defaults are assumed:

To change the attributes of an application from these defaults, you need to create a module definition file.

If you delete the EXETYPE statement, the linker can determine what kind of executable you want to produce from the options you supply on the command line.

You can include an import library to substitute for the IMPORTS section of the module definition.

You can use the __declspec(dllexport) or _export keywords in the definitions of export functions in your C and C++ source code to remove the need for an EXPORTS section. Note, however, that if __declspec(dllexport) or _export is used to export a function, that function is exported by name rather than by ordinal. Please also note that __declspec(dllexport) is the preferred method of export.

Linker-State Files

The four linker-state files have the following file extensions:

• .ILC (linker code file)
• .ILD (linker data file)
• .ILF (linker other file)
• .ILS (linker symbols file)

These four files are required for incremental linking.

You can control the linker state files on the Project > Options > C++ Linker page, as follows:

• To disable the creation of the linker state files, check the Disable incremental linking (-Gn) option.

• To clear the current linker state files and create new ones in the next link operation, check the Clear state before linking (-C) option.

Debug Information File

If you include debug information in your final linked executable, ILINK32 will always store the debug information in a separate TDS debug file, named

.tds by default. The debugger should be able to read this debugger-information file. ILINK32 will always create this file. If you do not have the -v (or /v ) linker switch set, the debug symbol file is marked as invalid.

DCC32.exe (the Delphi compiler) has a command line switch -VT for generating debug symbol files. You can also specify that the Delphi compiler is to generate debug symbol files by enabling Place debug information in separate TDS file on the Linking page of Project Options.

ILINK64

ILINK64 is the linker for C++ 64-bit Windows applications. Command syntax and usage for ILINK64 are the same as those of ILINK32. The main differences between the two C++ linkers for Windows are:

• ILINK32 links .obj and .lib files into a 32-bit Windows executable or .dll .
• ILLINK64 links .o and .a files into a 64-bit Windows executable or .dll .

With these main differences, you use the two linkers in the same ways.

Handling ILINK64 Errors

BCC64 Errors and Warnings describes handling the following error from ILINK64, the C++ linker for 64-bit Windows:

Some projects have a large amount of debugging or other data that can cause errors in the linker using its default settings. For information on how to handle this type of error, see Handling Linker Out of Memory Errors or learn more about the Split DWARF feature that helps you reduce the linker memory usage.

Источник

Errors and Warnings of Clang-enhanced C++ Compilers

Contents

Controlling Warning Messages

The option Enable all warnings (on Project > Options > C++ Compiler > Warnings ) invokes the compiler with the -Weverything option, which is a superset of -Wall (for all «easy to avoid» constructions).

Warnings may be enabled or suppressed individually, which requires the name of the warning. To show these names, pass -fdiagnostics-show-option to the compiler. Doing so changes a warning like this:

You can then use -Wunused-variable to turn on that warning specifically, without enabling others. To disable that warning, replace the leading -W with -Wno- , and use it in combination with an option to enable the desired warning level. For example: -Wall -Wno-unused-variable will enable all easy to avoid warnings except for unused variables.

Common Errors Porting from BCC32

Code ported from BCC32 may exhibit some of these errors (listed alphabetically, ignoring placeholders like ‘x’).

‘x’ does not refer to a value (in template)

Type names that are dependent on the template parameter must be preceded by typename . Without it, for example:

a * intended for pointer declaration will actually be interpreted as multiplication; and if the intended variable already happens to be in scope, this error will occur, trying to multiply a type name (‘member’ in this example), which is not a value.

Missing ‘typename’ prior to dependent type name ‘x’

Type names that are dependent on the template parameter must be preceded by typename . When omitted, some edge cases may generate other errors, but in general the error and solution is clear.

Pasting formed ‘x’, an invalid preprocessing token

Token pasting with the preprocessor’s ## operator must form a single valid token. In many cases, the operator is not necessary in the first place, so simply removing it resolves the issue.

Public symbol ‘x’ defined in both module A and B

Static data members should be declared in a header, and defined only once in a source file (not the header).

Use of undeclared identifier ‘x’ (in template)

Due to two-phase name lookup in templates, identifiers found in base classes are not resolved unless qualified with this->

Also, type names that are dependent on the template parameter must be preceded by typename . Without it, for example:

a * intended for pointer declaration will actually be interpreted as multiplication; and unless the intended variable already happens to be in scope, this error will occur, trying to multiply the template-value with the undeclared identifier (‘var’ in this example).

Common Warnings Porting from BCC32

Code ported from BCC32 may exhibit some of these warnings (listed alphabetically), which may be suppressed.

Conversion from string literal to ‘char *’ is deprecated

Assigning a plain char pointer to a literal C-string is discouraged. Make the pointer const (and if appropriate, consider using std::string ).

Implicit conversion changes signedness

BCC32 ignores an assignment from signed to unsigned. Clang-enhanced C++ compilers do notice such assignments, and emit a warning or error message.

Источник

Ilink64 error public symbol defined in both module

Please contact us if you have any trouble resetting your password.

It may be an IDE specific problem but i encountered some weirdo voodoo situation with no ideas how to perform next.

I have two different projects (in two different folders) one for windows second for android. (i compile them on windows anyway)

For one i use Android Studio for second one i use RAD Studio, anyway they are two separated project sharing a library folder with source.

basically to share shared libraries i used:

mklink /D c:anroidproject1/share e:shared_lib

mklink /D e:projectsc++winproject2share e:shared_lib

Now shared libraries need to know either i want to compile WINDOWS or LINUX port so in each project root folder (which contains this share folder) i place three fies: PORTDEF.h, PATHDEF.h, PATH_DEF.cpp

where i put defines: (well actually ill show you the code maybe its important however header guards are used)

now in android project i have a main glcode.cpp file where i include

#include «PORT_DEF.h»
#include «PATH_DEF.cpp»

and files in share folder use them too in manner of that they are included with relative path

#include «../PORT_DEF.h»
#include «../PATH_DEF.cpp»

Hit build everything is fine and works…

However… on windows

There are 3 units. One is Project.cpp (which is the main compilation file) and Unit1.cpp, Unit2.cpp (along with their headers)

During writing this post i faced new issues so lets get over with it:

i hit compile and get multiple definition of ‘DATA_PATH’

No having no idea what would cause that, i started poking around and ended with something like that:

in file share/sharedlib1.h cannot find file “.PORTDEF.h” @ #include “../PORT_DEF.h”

After an hour of trys and fails, i came with an idea to to add PORT_DEF.h to a project. (so it wil be visible for compiler)

but this requires me to change from #include “../PORTDEF.h” to #include “PORT_DEF.h”

i tried this in Androdi Studio (basically added this to cmakelists.txt)

error: CMakeFiles/s/gl_code.cpp.o: multiple definition of ‘DATA_PATH’

so i actually reproduced the same error on two IDEs now how i am supposed to to get rid of this multiple definition thingy.

I was searching for circular references there are none

basically these are all files included

all cpp files have headerguards (ones that are included in #include) the same goes for all headers they too have headerguards

yet still even when including

PORT_DEF.h AND PATH_DEF.cpp at the beggining of project they shoul reside there

yet when hitting another file which uses these files it rants about mutiple declaration. . IM OUT OF IDEAS

This sounds really interesting and I guess there is no easy solution because of your overall setup. First, you don’t need header guards in your CPP files as every compilation unit runs exactly 1 single cpp file to produce object code unless you included cpp files anywhere which is a no-no and should be done only if there is no other option to achieve what you need.

Second, naming your header guards: You should take care that you don’t use “simple” naming for them. Are you sure there is not a file that already defines PATH_DEFH? My naming for those guards is always like the filename except I replace every dot by an underscore. For example

This helps to avoid most cases of unintended definition clashes for me.

Something you might want to try is to resetup your projects. Start with a new clean solution and set include paths properly to the folder at which you store your shared libraries code and use the library sub-folder to prefix inclusion. Our build tool for example generates such inclusion entries in for example Visual Studio in a way that it adds the module root folder to the project as include path and we barely have files in the module root but store everything in a sub-folder. This way our includes always are either common for everything that is not specific to any module and then we have for example the Math folder in the Math module that then prefixes the include of anything inside it. For example

Finally this helps at least to determine where each file came from

Источник