Compiling on the shared CentOS server is not allowed. Therefore, I compile my program in my Debian computer, linking it with Debian's system libraries such as libc, etc. Then I upload my program and the Debian system libraries and my program works. The only problem is that setlocale() does not work at CentOS. CentOS has "en_US.utf8" installed and works on all programs except mine. I suspect that I have to also upload Debian's locale files ? How could I link my program to the Debian locale files ? I tried to use LOCPATH but I am unsure of how it works exactly. Which files do I have to link to and how ?
C program:
setenv("LOCPATH", "/", 1);
if (setlocale(LC_ALL, "en_US.utf8") == NULL) {
puts("not set");
}
I used a hex editor to modify the path to /usr/lib/locale/locale-archive which apparently is the only file that setlocale() uses according to strace. This method is dirty but it worked.
According to man LOCPATH, this environment variable is non-standard, so its use is not recommended. No examples are given anywhere of how to use it nor what is meant exactly by a path to "locale's object files".
I guess the only real way of modifying the path is a glibc modification and recompilation.
Quote: LOCPATH is an environment variable that tells the setlocale() function the name of the directory from which to load locale object files. If LOCPATH is not defined, the default directory /usr/lib/nls/locale is searched. LOCPATH is similar to the PATH environment variable; it contains a list of z/OS UNIX directories separated by colons.
So just specifying / and hoping that it does a recursive search will not work.
You could also produce a static binary and upload that to the host.
Related
At the moment I am able to compile and run a basic "Hello World" programme by using the windows command prompt via the command:
tcc.test.c
followed by
test.exe.
where test is the name of the file contaaing the code for the "Hello World" programme.
I installed the tcc folder ontop of my c:\ drive. I have another programme that requires the gsl library to run but I don't know from where and how to correctly install the library and how to call it when the programme compiles and runs.
you might want to read the documentation at: ;.
which, amongst other things says:
-Bdir Set the path where the tcc internal libraries can be found (default is PREFIX/lib/tcc'). "
Also of interest is:
-Idir' Specify an additional include path. Include paths are searched in the order they are specified. System include paths are always searched after. The default system include paths are: /usr/local/include', /usr/include' and PREFIX/lib/tcc/include'. (PREFIX' is usually /usr' or/usr/local'). "
and finally:
-Ldir' Specify an additional static library path for the-l' option. The default library paths are /usr/local/lib',/usr/lib' and `/lib'.
-lxxx' Link your program with dynamic library libxxx.so or static library libxxx.a. The library is searched in the paths specified by the-L' option.
I'm writing a Java compiler in C just as a recreational project. But, I've noticed that when we compile files in the command line, such as "gcc example.c", the compiler is able to find example.c in the working directory of the terminal without error. How does the compiler know what directory to search example.c for? Does OS find example.c in the directory for the compiler? Also, how may I emulate this action in my C program so that the user can compile their java program from any working directory by calling my compiler such as: "compiler example.java"?
fopen will treat relatives paths as relative to the current directory, not the directory where the executable resides. This is the same with most (or even all) file handling function in most other languages.
So to emulate the behaviour of the Java compiler, all you need to do is to iterate over the file names in argv, fopen(the_file_name), generate code for that file, then fopen(class_file_name, "wb") (where class_file_name is file_name with .java replaced by .class) and write the generated bytecode to that.
Getting the full path of the current directory is neither necessary nor helpful. Note that if you just appended each argument to the current directory name, the code would break for absolute paths, whereas simply doing nothing will do the correct thing both for relative and for absolute paths.
If I understand correctly, you need to obtain the full path of the current working directory. There is a POSIX function getcwd (on Windows _getcwd) that can be used to retrieve current working directory of your program.
Then it should be simple to search this directory and find your sources (if they are present).
I am curious about using dlopen in Linux to call shared libraries.
Suppose I want to use a shared library in C whose name is fileName.so. I am working in a 64bit Ubuntu Linux and I include dlfcn.h and use dlopen function to access the shared library.
When I use dlopen(fileName.so, RTLD_LAZY), a NULL handle is returned and shared library is not opened. However, when I use dlopen("./fileName.so", RTLD_LAZY) the dlopen does its job and opens the shared library. It seems that the main point is in using ./ before file name.
It is appreciated if help me figure out why I should use ./ in my code. Thanks
POSIX says that dlopen() has to know where to look for the file and leaves the behaviour when the file name does not include a / implementation defined. On Linux, if you don't supply a pathname (a name with a / in it somewhere), then dlopen() only looks in 'standard places', specified by environment variables such as LD_LIBRARY_PATH or via /etc/ld.so.conf (or /etc/ld.so.cache; see also ldconfig(8)) or in standard places such as /lib and /usr/lib.
When you specify the relative name ./fileName.so, it knows to look in the current directory, which is not normally a place it looks.
Note that you can run into some interesting issues on systems that support both 32-bit and 64-bit executables, with various conventions being used for the locations of the different classes of library. Other variants of Unix use vaguely related systems — mostly using dlopen() et al these days (historically, it was not always thus), and using a wide variety of environment variables (DYLD_LIBRARY_PATH, LIBPATH, SHLIB_PATH, LD_RUN_PATH, LD_LIBRARY_PATH_32, LD_LIBRARY_PATH_64, ...).
./ is a relative path to the .so file. It means that the file is in the current directory.
In *nix, by default, when given a file name without an absolute or relative path, dlopen will search for the library in a set list of default locations.
The "main point" is in using double-quotes in your second example:
dlopen("./fileName.so", RTLD_LAZY)
If you want to include your own library/filename enclose it in double-quotes. You don't even need the ./ for that, provided that the file is in the current directory, as ./ suggests.
As per the dlopen manpage's example:
handle = dlopen("libm.so", RTLD_LAZY);
if (!handle) {
fprintf(stderr, "%s\n", dlerror());
exit(EXIT_FAILURE);
}
the filename is enclosed in quotes.
Though, as specified by a previous answer, dlopen will look in the "standard" places for "includes". Another way of including a library that's inside your working directory (though, obviously, not a shared system library) is to use the preprocessor directive with the filename enclosed within double quotes:
#include <stdio.h>
#include <stdlib.h>
#include "myCustomLibrary.h"
Can someone explain to me why, in particular, we are using ./a.out to run a program?
Is there any meaning behind this?
Can someone please provide an explanation?
The name stands for "assembler output", and was (and still is) the default name for the executable generated by the compiler. The reason you need ./ in front of it is because the current directory (.) is not in $PATH therefore the path to the executable must be explicitly given.
If you mean the ./ part, it's for safety. Windows by default appends current directory to PATH, which is bad (there's a risk of DLL injection, and so on).
If you mean a.out part, it's just a name (which came from name of format a.out), which you can change by modifying gcc -o parameter.
When running an executable like a shell like bash the executable must be in your PATH environment variable for bash to locate and run the program.
The ./ prefix is a shorthand way of specifying the full path to the executable, so that bash does not need to the consult the PATH variable (which usually does not contain the current directory) to run it.
[For a.out (short for "assembler output"), it is the default executable output for a compiler like gcc if no output filename is specified.]
It'd be worth you looking a bit more into C and the way that C programs are compiled.
Essentially, your source code is sent to the preprocessor, where directives like #define and #include are loaded (e.g. into memory). So any libraries you want to use are loaded, e.g.
#include <math.h>
will basically 'paste' the contents of math.h into source code at the point at which it is defined.
Once all this stuff has been expanded out, the compiler turns your source code into object code, which is your source in binary code. a.out is the default name for output if you do not specify a build name.
gcc -o mynewprogram mynewprogram.c
a.out is the default name for the compiler. AFAIK it is because the linking process is skipped and it is not compiled as an object or library.
I am running Ubuntu 10.10 on an IBM R51 machine. When I access list.h to read it(manually/humanly) I open /usr/src/linux-headers-2.6.35-22/include/linux .
But when coding a C program in terminal, I cant invoke any #include because it is not in the default /usr/include folders.
When I change the statement to reflect the path by typing #include "/usr/src/linux-headers-2.6.35-22/include/linux/list.h" it returns errors as list.h in turn calls other header files which are mentioned as located in "linux" folder
The header files are as you must be aware:
"linux/poison.h", "linux/prefetch.h" and "asm/system.h"
So if I have to copy each, I can but prefetch in turn calls other dependencies, which are not present in /usr/include directory. I hope you understand.
How can I solve this problem?
Are you sure these headers are really what you need ? The standard C headers should be under /usr/include
Anyhow you need to pass the header search path to the compiler via the '-I' flag.
Pass the path via -I
-I/usr/src/linux-headers-2.6.35-22/include/linux
Then in your C code
#include "list.h"
Link to GCC manual & preprocessor directives
The header files you are using are designed for internal use of the Linux kernel. They were not designed to be used by a userland program.
If you MUST use these headers (the Linux kernel list implementation is brilliant), copy the headers into your program source directory. Copy each file that is referenced, edit each one to remove whatever assumptions exist about being used in-kernel, and recurse until you're finished. I might suggest to make your own prefetch() macro that simply does nothing, rather than try to untangle <linux/prefetch.h>. Do the same for <linux/poison.h>, and untangle <linux/types> and <linux/stddef.h> (not too hard here :) as best you can.
And also be sure you license your project GPLv2 (and specifically GPLv2, the Linux kernel's COPYING file is quite strict that GPLv2 is the only license that applies; there is debate whether the GPL allows specifying only one version, but that is the license Linus chose ages ago, and the license that is valid on all files unless specified otherwise).
adding -I/usr/src/linux is a no-go, since unsanitized header files are not meant to be used from user programs
you could manually copy list.h to your own project and sanitize
or use a library that is specifically for userspace and provides the same functionality (since you already used libHX elsewhere, you might want to continue reading into the linked list chapter)