I am trying to use an external library from Pascal that I have successfully used from C before. In order to use this library I have been provided a .h file, a .dll file and a .lib file.
I converted the .h file using the h2pas utility but I am getting the following errors (which I suspect are linker-related):
Error: (5009) Forward type not resolved "XPRSbranchobject"
This appears to be the offending line:
type
...
XPRSbranchobject = ^xo_user_branch_entity_s ;
How do I let Lazarus know that xo_user_branch_entity_s is part of the external library?
You could simply write:
type
xo_user_branch_entity_s = record
a: integer; // <-- probably redundant
end;
XPRSbranchobject = ^xo_user_branch_entity_s;
You must be sure you never (de)allocate such object (the record, either directly or via pointer); if the sources tries to access internal members, the compiler will complain.
This implies that allocation/deallocation is done by the DLL.
It should (could?) work...
Related
I have a proto file written in proto2 syntax. I am compiling this proto file using proto3 compiler. Although it bulids successfully, it shows the following error on runtime. Can someone please help me.
[libprotobuf FATAL google/protobuf/extension_set.cc:102] Multiple extension registrations for type "x.y.z.a", field number 200.
terminate called after throwing an instance of 'google::protobuf::FatalException'
what(): Multiple extension registrations for type "x.y.z.a", field number 200.
The error indicates that, somehow, your program has two copies of the definition for this extension. This is probably not protoc's fault, but rather some bug in the way your program is being built.
Here's my theory: You proto file has been separately compiled and linked into two different components/libraries, that are both then being loaded into the same program. One of these components is yours, the other is someone else's that shares the same protocol. The other component was already using protobuf 3.5.1 before, but yours was using 2.3.0. This means you actually had two copies of libprotobuf in your program. Because of this, the two copies of the extension were loaded using different copies of libprotobuf, therefore there was no error. But now you've switched your component to use protobuf 3.5.1, and so now only one copy of libprotobuf is being loaded, and both copies of the proto file are being loaded into that one copy of libprotobuf. So now, you get an error.
To fix this, you need to make sure that your program contains exactly one compiled copy of every proto file. If two components need to share a protocol, then that protocol needs to be factored out into a separate component to be shared.
It sounds like you have a message x.y.z.a, and you have multiple places where you define an extension with id 200 for it.
So something like this:
package x.y.z;
message a {
extensions 200 to 255;
}
extend a {
optional int32 foo = 200;
}
extend a {
optional int32 bar = 200;
}
So check for such duplicated extensions, which could be defined in multiple files.
I'm generating a Go file (to include constants such as build version etc) so that the constants can be used in other packages. I have a created a small tool that will create the file with go generate but am trying to think of an appropriate name so that
It is obvious that it is generated, so if it is missing (on build) the user then knows to run go generate
And I can then add the file to the .gitignore
My first guess is something like version_GENERATED.go
Any conventions I should be aware of or better suggestions?
Having a suffix like _GENERATED added to the file name does not hold any information until the file is generated, as the compiler will just give you "unrelated" errors like "undefined: xxx" (the compiler won't guess that if the identifier would exists, it would be in version_GENERATED.go).
For example the stringer generator generates files with name type_string.go where type is replaced with the name of the type it is generated for.
So I think simply following the general guidelines for file names is enough, except maybe use _gen or _generated suffix. Or if your tool is public and used by others too, then use the name of the tool as the suffix (like stringer does).
If you do want the user to get a talkative error message in case your generator is yet to be run, your generator may generate an exported constant whose name is talkative if included in an error message, like:
const MustRunStringerGenerator = 0
And in your program refer to it like:
var _ = MustRunStringerGenerator // Test if stringer has been run
If stringer has not yet been run, you'll see an error message:
undefined: MustRunStringerGenerator
I'm trying to write a program in C++ which runs Conway's Game of Life. I think I have everything that I need, but I'm having some trouble with compiling.
The program is composed of four files: gameoflife.h, a header file which contains my global constants and function declarations, gameoflife.cpp, which defines the functions, main.cpp, which uses the functions, and seeds.cpp, which contains a list of predefined seeds to be used.
When I go to compile the application, I seem to have a clash of duplicate symbols between main.cpp and gameoflife.cpp over an array called currGen which is declared in gameoflife.h.
Both main.cpp and gameoflife.cpp include gameoflife.h, which of course is necessary so that they have access to the global constants and function declarations.
The exact error I receive is the following:
duplicate symbol _currGen in /(same_path)/ConwaysGameOfLife.build/Objects-normal/
x86_64/gameoflife.o and
/(same_path)/ConwaysGameOfLife.build/Objects-normal/x86_64/main.o
for architecture x86_64
Command /Developer/usr/bin/clang++ failed with exit code 1
I've looked around on Stack Overflow but haven't found anything which matches my problem. Any help would be greatly appreciated!
You are probably defining the variable currGen in your header file, not just declaring it.
There needs to be exactly one definition, in one .cpp file. The .h file should just declare it, using extern.
This answer goes into much more detail.
How does a compiler detect duplicate definition across translation unit. Suppose there were a extern const variable declaration in an header file. If this header file was used in more than one translation unit - each having a separate definition - each TU object creation would be successful, however when the final executable is created the error is thrown.
Is there a reference table created to account these duplication while linking each of these TU (during the creation of the executable)?
Any link on this topic would be helpful.
Thanks in advance for your explanation.
Normally this would be detected by the linker, rather than the compiler. The linker can then either coalesce the variables (often required for sloppy C/C++ coding) or report an error.
Yes, the linker builds a list of unresolved external references and then eventually goes on to attempt to resolve them one by one.
i am building a C project with Xcode and when ever i build it it gives me this error:
ld: duplicate symbol _detectLinux in /Users/markszymanski/Desktop/Programming/C/iTermOS/build/iTermOS.build/Debug/iTermOS.build/Objects-normal/i386/linuxDetect.o and /Users/markszymanski/Desktop/Programming/C/iTermOS/build/iTermOS.build/Debug/iTermOS.build/Objects-normal/i386/iTermOS.o
Thanks!
This means you have defined the same symbol with global scope in (at least) two different source files -- either a function or a global variable called _detectLinux, and apparently in the files linuxDetect.c and iTermOS.c.
How to fix it depends on how you intend to use this symbol:
If you meant to define it in one file and use it in the other file, declare it extern in the other file.
If you only intend to use the symbol in the file that it is declared in, you can declare it static.
If the symbol is defined in both files, you can rename the symbol in one (or both) files.
If _detectLinux is a function, one common way to get this problem is to define it in a header file but forget to mark it inline. This would cause it to generate the function code in each file that includes the header (presumably _detectLinux.c and iTermsOS.c).
Alternately perhaps you copy-pasted the entire body of the function between the two source files instead of simply declaring the function in iTermsOS.c where I expect it's being called.
Well, that's not much information to go on. As the error says, the symbol _detectLinux is included in both linuxDetect.o and iTermsOS.o and when you try to link them together, there is a conflict since the linker does not know which of the two symbols to use. This might happen if you, for example, have a global variable with that name in a .h file which is used to build both files instead of declaring it in one place and declaring it as "extern" in the .h file.
What you need to do is look at where the symbol _detectLinux is originally declared, then trace through the dependencies for both linuxDetect.o and iTermOS.o to see why it is being included publicly in both.