gnucobol gcc: error: `cob-config: No such file or directory - cobol

I'm trying to practice a C program (hello.c) calling cobol program (say.cob) from the manual gnucobol.
---- say.cob ------
IDENTIFICATION DIVISION.
PROGRAM-ID. say.
ENVIRONMENT DIVISION.
DATA DIVISION.
LINKAGE SECTION.
01 HELLO PIC X(6).
01 WORLD PIC X(6).
PROCEDURE DIVISION USING HELLO WORLD.
DISPLAY HELLO WORLD.
EXIT PROGRAM.
---- hello.c -
#include <libcob.h>
extern int say(char *hello, char *world);
int
main()
{
int ret;
char hello[7] = "Hello ";
char world[7] = "World!";
cob_init(0, NULL);
ret = say(hello, world);
return ret;
}
C:\Users\S M Rao>gcc -c ‘cob-config --cflags‘ hello.c
gcc: error: `cob-config: No such file or directory
gcc: error: unrecognized command line option '--cflags`'
if I run with commands
cobc -c hello.c
cobc -c -static say.cob
cobc -x -o hello hello.o say.o
getting following error
C:\Users\S M Rao>cobc -x -o hello hello.o say.o
hello.o:hello.c:(.text+0x5c): undefined reference to `say'
collect2.exe: error: ld returned 1 exit status
I can see cob-config is present in gnucobol folder. And in environment variables COB_CONFIG_DIR %COB_MAIN_DIR%\config
what could be the problem? any help please?

cob-config would need to be an executable script, which it commonly is.
As you specify windows paths I assume you use that - and this one cannot run shell scripts. You may get around that with and additional cob-config.bat that executes this shell script, but In this case it will output mingw/wsl/cygwin/... paths that likely cannot be used in the Windows gcc.
Solutions:
run gcc in the matching shell, not from the windows side and have cob-config as an executable script in $PATH
use cobc's feature to call the C processor (and if wanted also the linker) for you: cobc -c hello.c

Related

PANIC: unprotected error in call to Lua API (undefined symbol: lua_gettop)

My environment is Lua-5.4.2 Luasocket-3.0-rc1.
When I run lua script directly, it work success.
When i run it through c language, it tell me error.
Error Msg is :
PANIC: unprotected error in call to Lua API (error running script: error loading module 'socket.core' from file '/usr/local/lib/lua/5.4/socket/core.so': undefined symbol: lua_gettop)
Aborted(core dumped)
Does anyone know why?
lua script code is:(test.lua)
#!/usr/local/bin/lua
local socket = require("socket")
print(socket._VERSION)
c code is:(main.c)
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <stdlib.h>
#include "lua.h"
#include "lualib.h"
#include "lauxlib.h"
int main(void)
{
lua_State *L;
L = luaL_newstate();
luaopen_base(L);
luaL_openlibs(L);
printf("lua enter\n");
if (luaL_dofile(L, "test.lua"))
{
luaL_error(L, "error running script: %s", lua_tostring(L, -1));
}
printf("lua exit\n");
while(1) pause();
lua_close(L);
return 0;
}
tl;dr: Pass -Wl,-E to GCC.
I was able to reproduce your problem with this Dockerfile:
FROM gcc:11.1.0
RUN wget https://www.lua.org/ftp/lua-5.4.2.tar.gz \
&& git clone https://github.com/diegonehab/luasocket.git
RUN tar zxf lua-5.4.2.tar.gz \
&& cd lua-5.4.2 \
&& make linux \
&& make install \
&& cd ../luasocket \
&& git checkout 5b18e475f38fcf28429b1cc4b17baee3b9793a62 \
&& make linux LUAV=5.4 \
&& make install LUAV=5.4
COPY test.lua main.c ./
When I run lua test.lua in the resulting Docker container, it works fine. When I run gcc -o test main.c /usr/local/lib/liblua.a -ldl -lm -Wl,-rpath='/usr/local/lib/lua/5.4/socket' && ./test, I get the same panic that you get.
The reason that the standalone Lua binary works and yours doesn't is that the former is linked with -E:
MYLDFLAGS= $(LOCAL) -Wl,-E
ld's documentation for -E says this about it:
If you use dlopen to load a dynamic object which needs to refer back to the symbols defined by the program, rather than some other dynamic object, then you will probably need to use this option when linking the program itself.
Lua uses dlopen to load C modules that you require, and said modules need to call Lua functions, which are linked into your binary, so it makes sense that you need this option. And indeed, when I add -Wl,-E to the GCC command line, then it works fine for me:
root#077bbb831441:/# gcc -o test main.c /usr/local/lib/liblua.a -ldl -lm -Wl,-rpath='/usr/local/lib/lua/5.4/socket' -Wl,-E && ./test
lua enter
LuaSocket 3.0-rc1
lua exit

Gnucobol compiles .cob to .c failed to pass compiler of clang

I was trying to compile hello.cob to hello.c:
$ ls
hello.cob
$ cobc -x -C hello.cob
$ ls
hello.c hello.c.h hello.c.l.h hello.cob
But clang failed to compile hello.c to executable file:
$ clang hello.c
/tmp/hello-479acf.o: In function `main':
hello.c:(.text+0x1e): undefined reference to `cob_init'
hello.c:(.text+0x2a): undefined reference to `cob_stop_run'
/tmp/hello-479acf.o: In function `sampleCOBOL_':
hello.c:(.text+0x98): undefined reference to `cob_module_global_enter'
hello.c:(.text+0x133): undefined reference to `cob_display'
hello.c:(.text+0x13f): undefined reference to `cob_stop_run'
hello.c:(.text+0x15a): undefined reference to `cob_check_version'
hello.c:(.text+0x33d): undefined reference to `cob_set_cancel'
hello.c:(.text+0x38e): undefined reference to `cob_fatal_error'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Here is hello.cob (can be compiled by cobc -x hello.cob):
IDENTIFICATION DIVISION.
PROGRAM-ID. sampleCOBOL.
PROCEDURE DIVISION.
DISPLAY "Hello World!".
STOP RUN.
I'm quite sure clang doesn't fail to compile the C source as you don't ave any C compiler warnings or errors.
It cannot link the generated object file because you didn't told clang to link against libcob and there is no "magic" for clang to know where to find its symbols. Adding -lcob to your clang invocation may be enough already.
If you want to know how cobc invokes the compiler/linker add -v to your cobc invocation.
Note: if this version of cobc was built with gcc it defaults to use gcc, too. You can see this with cobc --info which also shows if any of the built-in commands is override by environment variables.
Additional note: cobc does not only call a C compiler/linker, it also generates C code specific for the compiler it was built with. The most important part concerning the C generation is -f[no-]computed-goto, just in case the C compiler complains (which it doesn't in your case).

what are the args that are being passed from clang to llc?

I am working on the llvm project. Recently I tryed to compiler one of my .c files using clang command line into an .s file by using the next command:
clang --target=arch -S -O0 select.c -o select.s
and it crashed in the backend in the function ARCHInstrInfo::storeRegToStackSlot with the backtrace of the stack.
However when I tryed to do it in steps:
clang -O0 -emit-llvm select.c -c -o select.bc
llc -filetype=asm -march=arch ./select.bc -o ./select.s -print-after-all -debug-only isel
it succeeded !! (?)
How can I see how the clang is calling to the backend (llc) ?
I tryed to run the clang with -v flag but it didn't printed how it is calling to the backend...
So the first one that sticks out is that llc defaults to O2 rather than O0 so you might want to look there first.

C/XCode: sh: ./child: No such file or directory. Command runs in terminal but not XCode

So I have a child.c file and I want to compile and run it in my main.c file using the system() function of stdlib.h.
child.c:
#include<stdio.h>
int main(){
printf("I am the child\n");
return 0;
}
main.c:
#include <stdio.h>
#include <stdlib.h>
int main() {
system("cd ~/Desktop/HW3/HW3");
system("gcc -o child child.c");
system("./child");
return 0;
}
everything worked fine when I compile and run main.c in terminal using the following command
abcs-mbp:HW3 abc$ cd
abcs-mbp:~ abc$ cd ~/Desktop/HW3/HW3
abcs-mbp:HW3 abc$ gcc -o main main.c
abcs-mbp:HW3 abc$ ./main
and it ran child.c and printed the following:
I am the child
but when I tried to run the exact same main.c in XCode, XCode gave me the following error:
clang: error: no such file or directory: 'child.c'
clang: error: no input files
sh: ./child: No such file or directory
anybody know why this is happening? I think it has something to do with path, but how can I tell XCode the path of child.c and then tell it to compile child.c?
I also tried
system("cd ~/Desktop/HW3/HW3");
system("gcc -o child child.c");
system("./child");
and
system("/Users/vqianxiao/Desktop/HW3/HW3/ gcc -o child child.c");
but nothing seems to work... any help is appreciated!
the reason that it does not work is a combination of things
1) each 'system' call is run in a separate shell instance,
so the second 'system' call
starts from the directory where the main program is running.
2) things do down from there
a suggested fix:
system("cd ~/Desktop/HW3/HW3; && gcc -o child child.c; && ./child;");
notice, all one system call, terminators at end of commands, and linked by && so one command must be successful to continue on to the next command

LLVM cannot find clang binary

I have just built and installed LLVM Clang 3.5.0 with compiler-rt. clang binary seems to work, but cannot build a simple test program:
$ cat hello.c
#include <stdio.h>
int main(int argc, char **argv) {
printf("Hello World\n");
return 0;
}
Building it borks with error: unable to execute command: Executable "" doesn't exist!
$ clang hello.c -o hello
error: unable to execute command: Executable "" doesn't exist!
Executable "" ? Interesting...
Debugging it further reveals that clang tries to call itself to build .o object file and then ld to link it, but does not know where itself exists apparently.
$ clang -### hello.c -o hello
clang version 3.5.0 (tags/RELEASE_350/final)
Target: x86_64-alpine-linux-musl
Thread model: posix
"" "-cc1" "-triple" "x86_64-alpine-linux-musl" "-emit-obj" "-mrelax-all" "-disable-free" "-main-file-name" "hello.c" "-mrelocation-model" "static" "-mdisable-fp-elim" "-fmath-errno" "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-fuse-init-array" "-target-cpu" "x86-64" "-target-linker-version" "2.24" "-dwarf-column-info" "-resource-dir" "../lib/clang/3.5.0" "-internal-isystem" "/usr/local/include" "-internal-isystem" "../lib/clang/3.5.0/include" "-internal-externc-isystem" "/include" "-internal-externc-isystem" "/usr/include" "-fdebug-compilation-dir" "/" "-ferror-limit" "19" "-fmessage-length" "158" "-mstackrealign" "-fobjc-runtime=gcc" "-fdiagnostics-show-option" "-o" "/tmp/hello-37746e.o" "-x" "c" "hello.c"
"/usr/bin/ld" "-z" "relro" "--eh-frame-hdr" "-m" "elf_x86_64" "-dynamic-linker" "/lib/ld-musl-x86_64.so.1" "-o" "hello" "/usr/bin/../lib/gcc/x86_64-alpine-linux-musl/4.8.3/../../../crt1.o" "/usr/bin/../lib/gcc/x86_64-alpine-linux-musl/4.8.3/../../../crti.o" "/usr/bin/../lib/gcc/x86_64-alpine-linux-musl/4.8.3/crtbegin.o" "-L/usr/bin/../lib/gcc/x86_64-alpine-linux-musl/4.8.3" "-L/usr/bin/../lib/gcc/x86_64-alpine-linux-musl/4.8.3/../../../../x86_64-alpine-linux-musl/lib" "-L/usr/bin/../lib/gcc/x86_64-alpine-linux-musl/4.8.3/../../.." "-L/../lib" "-L/lib" "-L/usr/lib" "/tmp/hello-37746e.o" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "/usr/bin/../lib/gcc/x86_64-alpine-linux-musl/4.8.3/crtend.o" "/usr/bin/../lib/gcc/x86_64-alpine-linux-musl/4.8.3/../../../crtn.o"
When I run the first line putting /usr/bin/clang as the first item, it builds just fine:
$ /usr/bin/clang "-cc1" "-triple" "x86_64-alpine-linux-musl" "-emit-obj" "-mrelax-all" "-disable-free" "-main-file-name" "hello.c" "-mrelocation-model" "static" "-mdisable-fp-elim" "-fmath-errno" "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-target-cpu" "x86-64" "-target-linker-version" "2.24" "-dwarf-column-info" "-resource-dir" "../lib/clang/3.5.0" "-internal-isystem" "/usr/local/include" "-internal-isystem" "../lib/clang/3.5.0/include" "-internal-externc-isystem" "/include" "-internal-externc-isystem" "/usr/include" "-fdebug-compilation-dir" "/" "-ferror-limit" "19" "-fmessage-length" "158" "-mstackrealign" "-fobjc-runtime=gcc" "-fdiagnostics-show-option" "-o" "/tmp/hello-4f64bb.o" "-x" "c" "hello.c"
$
And following /usr/bin/ld is able to link it just fine resulting in:
$ ./hello
Hello World
Anny suggestions what did I screw during configure/build?
clang source analysis shows that 'clang' program on Linux uses /proc/self/exe to find out real path of its binary. I am running in chroot without /proc mounted, thus it failed.
mount -t proc proc /proc
solves the issue

Resources