I am trying to build a Github repository(https://github.com/rougier/freetype-gl) using cmake. The below error shows up:
expected identifier or '(' before '.' token ../texture-atlas.c
Background: The folder contains a file called texture-atlas.c which has just this one line:
../texture-atlas.c
There is also a file by the same name in the parent directory which is being referred. How do I go about fixing this error?
That file is supposed to be symbol link, pointing at the file ../texture-atlas.c (i.e. this file).
In Linux, symbolic links are represented as text files containing the path to the link target, and a special meta-info flag in the file system that says "this is a symbolic link". That's why you get the target file name as the contents of the file, that's all that remains when the link flag doesn't exist.
You probably cloned the repo on a platform not supporting symbolic links. Try copying the file over the link.
Edit:
The installation instructions for Windows say:
Note: Harfbuzz examples only work with symbolic links enabled. See https://github.com/git-for-windows/git/wiki/Symbolic-links.
So you should probably follow that link, and see what to do.
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 running the pc lint misra checks on my project.
When I execute the program the output is huge because it includes all the bsp files from arm. How do I get pc-lint to exclude a whole directory. In the code when I include a header file from outside the project I use <> instead of ""
i.e. #include <arm_driver.h>.
I thought this was enough. Is their another step missing?
These are the additional parameters I have passed
+libclass(angle, foreign)
-e686
-wlib(0)
And with the command vf I can see that all the external directory files are being treated as library headers.
Finally fixed the issue.
Comment out all the explicit +elib lines in the corresponding .lnt file.
i.e. replace all instances of +elib with //+elib
I need a method to obtain the absolute path of a file in C programming language for the implementation of 'cp' UNIX's command. The objective is show an error when the source path and destination path are the same.
There are multiple possibilities, for example:
cp file . // show error
cp ../file .
cp file file // show error
I haven't found a good method to solve this problem.
Converting comments into an answer.
Lookup realpath() to get the 'real name' of a path, but it really isn't necessary. You can use stat() to see if the device and inode number are the same for two names.
Also note that if you have two files linked (for example, /home/user1/name1 and /home/user2/name2), the names might be different but still refer to the same file (and the links could be 'hard' or symbolic). You can detect their equivalence with stat() but not with realpath() — at least, not with realpath() if the link is a hard link.
I was originally following this tutorial: http://www.opengl-tutorial.org/miscellaneous/building-your-own-c-application/
just after about half way down, from where it says "Adding a source file in a project"
I created from this my CMakeLists.txt file as so:
cmake_minimum_required (VERSION 2.6)
project (Cube_Project)
find_package(OpenGL REQUIRED)
add_executable(Cube
main.cpp
)
include_directories(
external/glfw-2.7.6/include/
external/glm-0.9.4.0/
external/glew-1.9.0/include/
.
)
set(ALL_LIBS
${OPENGL_LIBRARY}
GLFW_276
GLEW_190
)
target_link_libraries(Cube
${ALL_LIBS}
)
but when I generate the project, I get this error:
ld: library not found for -lGLFW_276
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Any ideas?
I think maybe I'm not using the right names in the set(....) section? My three libs are in a folder called external, which is the top level of the project (i.e. CMakeLists is also here).
I put a zip of the project if anyone wants to take a look at the folder layout of output XCode project structure: http://heather.sh/OpenGL_Project.zip
Thanks,
The library is not in the linker's library search path.
The target_link_libraries command is is very straightforward: It simply passes on all of its arguments to the linker without bothering whether any of those libraries actually exist.
In your case, the GLFW_276 library is missing (and possibly the GLEW_190 as well, since the error occurs before that one is being processed). Make sure the library is actually installed on your system and its filename actually matches the name you use here (eg. libGLFW_276.so).
Once you verify that you have the required file, you need to make sure that the linker is able to find it. If the file is not located in one of the standard directories, use either link_directories to add its location to the search path, or find_library to obtain the full path to the library file, which can then be given to target_link_libraries.
I was looking at getting HTML-XML-Utils working on my computer and I noticed the .e filetype in the source tree. Running:
% file types.e
types.e: ASCII c program text
reveals some clues about it and its use in C files seems to be that of a header file.
Can anyone reveal some more information or history about this filetype? I've tried my best Google-foo but I cannot find anything.
I never heard of that file type in connection with C before, but after checking the files and the Makefile it seems to be variables and functions that are exported, therefore the .e extension.
They seem to be created by a special program (which comes with the package) called cexport whose manual page states:
cexport - create header file with exported declarations from a C file