sorry I know it is repeated and it is similar to this question but there was only one answer which doesn't satisfy the objective :)
The compilation of uamqp library is pretty easy. I end up with 2 static libraries to be used when linking in my project in eclipse. During run time and if an error happens, the error message shows the path, where the static libraries are originally compiled. I get something like this:
Error: Time:Tue May 22 09:04:45 2018 File:/home/hostname/azure-uamqp-c/src/saslclientio.c Func:on_underlying_io_error Line:243 Error callback received in unexpected state
I have no problem with the error message. The issue is only when the error occurs, then it shows the path /home/hostname/azure-uamqp-c/saslclientio.c
Please how can I compile the uamqp library, so that no absolute paths are stored inside? is it a cmake command option that I do have to configure?
Thanks
Message "Error callback received in unexpected state" is emitted by LogError() call, and LogError macro eventually uses preprocessor expression __FILE__ for refer to the path of source file.
According to that answer, expression __FILE__ is expanded to path, which is passed in compiler's command line.
Unfortunately, CMake always uses absolute paths for source files when pass them to the compiler. So there is no easy way for generate relative paths in logs.
You may write a wrapper around compiler, which transforms absolute paths to relative and calls compiler.
Related
I want to compile the sqlite amalgamation to create a database which is protected by a password via user authentication.
I followed this tutorial: https://www.sqlite.org/howtocompile.html
And also the documentation by SQLite for the user_authentication: https://www.sqlite.org/src/doc/trunk/ext/userauth/user-auth.txt
When I try to compile it without the extra compile-time option "-DSQLITE_USER_AUTHENTICATION" and without adding the other documents it works. When I try to compile it with I get the error C2129 at sqlite.c and error C1083 at userauth.c
In this directory are the following files:
shell.c
sqlite3.c
sqlite3.h
sqlite3ext.h
sqlite3userauth.h
userauth.c
cl -DSQLITE_USER_AUTHENTICATION shell.c sqlite3.c userauth.c -Fesqlite3.exe
Following output:
shell.c
sqlite3.c
sqlite3.c(222878): error C2129: static function 'void sqlite3CryptFunc(sqlite3_context *,int,sqlite3_value **)' declared but not defined
sqlite3.c(16263): note: see declaration of 'sqlite3CryptFunc'
userauth.c
userauth.c(26): fatal error C1083: Cannot open include file: 'sqliteInt.h': No such file or directory
Generating Code...
In case there is something like C#'s db.SetPassword("MyPW") available in c, that would be perfect!
I followed [...] the documentation by SQLite for the user_authentication: https://www.sqlite.org/src/doc/trunk/ext/userauth/user-auth.txt
Well no, it doesn't look like you did. Those docs say
Activate the user authentication logic by including the
ext/userauth/userauth.c source code file in the build and adding the
-DSQLITE_USER_AUTHENTICATION compile-time option. The ext/userauth/sqlite3userauth.h header file is available to
applications to define the interface.
When using the SQLite amalgamation, it is sufficient to append the
ext/userauth/userauth.c source file onto the end of the amalgamation.
You are using the amalgamation, so you should append [the contents of] userauth.c to the amalgamation. That is, copy its contents to the end of sqlite3.c. From your directory listing and command line, it appears that you are instead attempting to build it as a separate source file, to be linked to the main one at the end. That's not equivalent, and in particular, it differs with respect to the effect on the scope of static functions and variables, which is exactly what your compiler is complaining about.
It's unclear whether -DSQLITE_USER_AUTHENTICATION should also be used with the amalgamation. A literal reading of the SQLite docs suggests not, but I would be inclined to guess that it actually is required either way if you want to enable the feature.
The error about the missing header is a little concerning, and it is possible that you will see it again. If you do, it may be sufficient to simply remove or comment out the corresponding #include directive, as all the needed declarations from that header, which is among the main sources, should already be included in the amalgamation.
I am trying to use the following method to include a project header file:
#include FILE_PATH
Where FILE_PATH is defined as the file to be included.
The project compiles without errors if FILE_PATH is include as:
#define FILE_PATH "hal/micro/config.h"
#include FILE_PATH
But if FILE_PATH is pre-defined as a compiler define option inside the project options, then building the project returns the following error:
Error #13: Expected a file name
The development software being used is Code Composer Studio version 6.
What am I missing here to pre-define the header file path in a project?
Additional Details:
I am in the process of converting a working project from the IAR embedded workbench IDE to Code Composer Studio. The Pre-define NAME (--define, -D) shown in the picture below are mostly identical to how they were in the IAR project.
The pre-define name boxed in red is currently the cause of the error, but this could occur with any of the other defines with file pathnames.
I have tried the suggestion of using the #ifdef statement to at least verify that PLATFORM_HEADER is actually defined and it does seem to be defined. I also checked for typos and there doesn't appear to be any noticeable typos.
The key reason for wanting to go with the pre-defined macro approach is to avoid individually making changes to numerous files affected by this error.
I still have not yet tried a command line compile, since I need to reference the manual on how to do so, but I will try as soon as I figure it out.
#StenSoft wrote:
The IDE does not correctly escape the parameters. You should escape the quotes. You can also try placing PLATFORM_HEADER somewhere in the code and see what the compiler would tell you it sees.
i'm trying to do some code in a keyboard driver, a 3rd party software that looks like this can run the command i'm trying to do in a plugin file that compiles alongside the daemon that the command needs to be sent to. the command looks like this.
g15_send_cmd (g15screen_fd,G15DAEMON_MKEYLEDS,mled_state);
here's the code i'm working with and trying to run the command in (it compiles as a plugin with the daemon. in the uncompiled source it's
"g15daemon/plugin/g15_plugin_uinput.c"
the file that defines the command is in
(link)
"g15daemon/libg15daemon_client/g15daemon_clinet.h"
whereas with the g15macro (3rd software) is run from outside the daemon for various reasons i don't want to (and pretty much can't) use it, one being speed of execution of commands when keys are pressed.
so the program compiles like this without error it seems. but if the code i specified above activates, the driver(daemon) crashes giving
g15daemon: symbol lookup error:
/usr/lib/g15daemon/1.9.5.3/plugins/g15plugin_uinput.so: undefined
symbol: g15_send_cmd
what did i do wrong or what am i missing here? (and i'm sorry if the code in the plugin file is ugly down by that switch command, but i didn't know how to do any better since i don't know C much at all, all i have behind me are Py and C#)
Edit: the solution was given
but i don't know how to add a linker flag, also since it links to a part of the program being compiled will it even work?
You forgot to link your plugin with g15daemon_client library. The simple way to fix it is to add -lg15daemon_client to the linker flags.
I had some lua code with the following line:
JSON = loadfile("JSON.lua")()
The file JSON.lua is in the same directory as the lua code that line came from. This code worked for me for a while, and then, without my changing either the lua source, or the JSON.lua, or permission of any of the files, or the directory from where I was running the lua code, I started getting a nil error on that line. (I simply recall NO relevant changes that could have any impact on the lua code.)
Adding an assert revealed that the error was caused by the file not being found. Playing with file permissions, restarting my machine didn't resolve the issue, and pulling back code that I had checked in and was working perfectly did not resolve the error.
I resolved the error by changing the line above to provide the absolute path to that JSON.lua file.
Is there anything explaining why the code without the absolute path could have worked for a while and then stopped working?
Note: This behavior of working and then not working happened to me twice over a week. I am puzzled and though I have now found a fix, I am really curious as to the explanation for that intermittent behavior.
Lua uses package.path, whose default value comes from the environment variable LUA_PATH if it is set, as the list of directories to search. You can put . of the front of this list to load files from the current directory, or you can put your files in a path on the list.
A late answer on this, as I found exactly the same problem.
First, contrary to the previous answer, loadfile doesn't use the package.path search path. It only looks in the specified directory. And if you don't specify a directory, it only look in the 'current directory'. I can't explain exactly why it stopped working for you, but probably your Lua code is somehow being run with a different 'current directory' than previous.
There are two possible fixes: One is to specify an absolute path to loadfile.
JSON = loadfile("c:\\my_folder\\JSON.lua")()
The alternative fix depends on the particular library you're using, which I suspect is Jeffrey Friedl's Lua JSON lilbrary. Because this supports the newer Lua module mechanism, you can just load the module with require, which does support the package.path search path.
JSON = require("JSON")
When I compile with Compaq Visual Fortran, I get these errors (when it starts the linker process) that should be located in a .lib file I thought I added to the workspace:
X30XFULL.OBJ : error LNK2001: unresolved external symbol _BCON#4
X30XFULL.OBJ : error LNK2001: unresolved external symbol _RCON#16
According to where I've googled about, it looks like Compaq Visual Fortran (Version 6, FYI) can't find the library files...
My main question is, how do I use them? Could there possibly be other missing files? Here is what I've tried:
Right Click->Adding the files in the FileView window
Going under Project->Settings, Clicking the Link tab, and under the input category, adding the library files under object/library modules (bprop.lib rprop.lib) and having the Additional Library Path point to where the files are. I also did this under the Resources tab and where it says "Additional Resource Include Directories," I put the directory of where these files were located.
To cover my bases, I also put these files in where the project workspace file, where the compiled executable file would be generated, and pretty much any place I could think of that CVF might possibly look to in order to find these files.
A little background:
I have this Fortran executable that was last compiled in the 90s. From my research, it's a 16-bit compiled one which won't work on a 64-bit machine.
The original code has, at least from what we can gather, 16 bit compiled libraries. Without the original compiler, we can't figure out how to look at or use them. We also have a (semi)equivalent library file that's actually a .FOR file. For all we know, the BPROP.FOR and BPROP.LIB could be the same file (they were found in the same source code area). If we use the BPROP.FOR file, the program can compile, but we are having issues with results that we've traced down to information that is used/gathered/processed in that file.
However, we do have 32-bit versions of (what we think) are the same .lib files. So, we're trying to use that, which is what is being used to compile the Fortran executable which results in the errors above.
Found the answer, at least for me. I don't know how easy it'll be to extrapolate if anyone else finds these answers, but this is how I solved it.
With the old Fortran libraries, all I had to do was add them to the FileList view that has all of the different fortran files (.FOR, etc). I did not have to add these libraries in the settings like I mentioned, but that will work as well. Other then that, I didn't need to add any extra declarations or anything similar.
What we did find out is that the function in question (BCON and RCON) that calls those .LIB files required an additional argument. The only way I found this out was examining other source code that used those libaries, so if anyone is stuck like I was, that would be a good place to start. Alternatively, if you can read the .lib file in a hex editor, you can kind of make out functions and their arguments.
Of course, if you have the original source code for said arguments, that's even better. :)