As default, Forth has only a little amount of working libraries so that everything has to be programmed from scratch. The reason is, that the stackbased Forth virtual machine identifies itself as a slim system.
According to the Gforth manual, it's possible to use existing C libraries and get access to precompiled graphics libraries and game-engines written in C. Before it's possible to include the C library in Forth, it's a good idea to test the library within a normal C project.
I've created a library in C from scratch. It provides an add function and can be called from the main program. The files are compiled and linked and it works fine.
### add.c ###
int add(int a, int b) {
return a + b;
}
### add.h ###
int add(int, int);
### main.c ###
#include <stdio.h>
#include "add.h"
void main() {
printf("5 + 7 = %d\n", add(5,7));
}
### compile ###
gcc -c -fPIC add.c
gcc -c main.c
gcc main.o add.o
./a.out
5 + 7 = 12
The plan is to use this precompiled c-library from Forth. The Gforth compiler provides a special keyword for that purpose which connects a Forth program with a C library. Unfortunately, I get an error message saying that the library wasn't found. Even after copying it manually to the Gforth folder, the error message doesn't disappear.
### Forth source code ###
\c #include "add.h"
c-function add add n n -- n
5 7 add .
bye
### Execution ###
gforth "main.fs"
/home/user1/.gforth/libcc-tmp/gforth_c_7F5655710258.c:2:10: fatal error: add.h: No such file or directory
#include "add.h"
^~~~~~~
compilation terminated.
in file included from *OS command line*:-1
b.fs:3: libtool compile failed
5 7 >>>add<<< .
Backtrace:
$7F56556BD988 throw
$7F56556F9798 c(abort")
$7F56556F9F08 compile-wrapper-function
gforth: symbol lookup error: /home/user1/.gforth/libcc-tmp/.libs/gforth_c_7F0593846258.so.0: undefined symbol: add
### Copy missing file and execute again ###
cp add.h /home/user1/.gforth/libcc-tmp/
gforth "main.fs"
gforth: symbol lookup error: /home/user1/.gforth/libcc-tmp/.libs/gforth_c_7F5256AC2258.so.0: undefined symbol: add
What's wrong with the “Forth-to-C interface”?
You have to declare add as a function for export, compile it as a shared library (e.g. libadd.so) and add this library using the add-lib word, see Declaring OS-level libraries.
s" add" add-lib
NB: prefix 'lib' and suffix '.so' are added automatically.
Related
I'm new to Fortran (gfortran on windows) and want to use the random number generator vsrnggaussian.
vsrnggaussian needs the Intel MKL VSL modules 'mkl_vsl_type' and 'mkl_vsl' which are provided in the mkl_vsl.f90 file. This file needs to be included to generate the module files 'mkl_vsl_type.mod' and 'mkl_vsl.mod' which are used to process the Fortran use clauses referencing to the VSL interface:
use mkl_vsl_type
use mkl_vsl
I tried multiple things to include the mkl_vsl.f90 file but none of them work:
I inserted the file into the project directory --> 793 errors occured (can't list all of them here in detail) such as:
Unexpected data declaration statement at (1)
[...] at (1) has no implicit type
expecting [...] statement at (1)
unexpected [...] statement at (1)
and finally Fatal Error: Cannot open module file 'mkl_vsl_type.mod' for reading at (1): No such file or directory. compilation terminated. "gfortran -g -o incl_mkl.exe ../incl_mkl.f90" terminated with exit code 1. Build might be incomplete.
I used the full path in the include statement: INCLUDE 'C:/Program Files (x86)/IntelSWTools/compilers_and_libraries_2016.1.146/windows/mkl/include/mkl_vsl.f90' --> Error: Can't open included file
I tried the -Idir compiler command: gfortran -I/Program Files (x86)/IntelSWTools/compilers_and_libraries_2016.1.146/windows/mkl/include/ -g -o incl_mkl.exe --> gfortran: error: Files: no such file or directory
I put this into the makefile: INCLUDES=-I. -I/Program Files (x86)/IntelSWTools/compilers_and_libraries_2016.1.146/windows/mkl/include/ --> Error: Can't open included file
How do I include the mkl_vsl.f90 file??
edit: my simple code to include the mkl_vsl.f90 file
(this code will be compiled first before i compile my main code with vsrnggaussian):
Program INCL
IMPLICIT NONE
INCLUDE 'mkl_vsl.f90'
!INCLUDE 'C:/Program Files (x86)/IntelSWTools/compilers_and_libraries_2016.1.146/windows/mkl/include/mkl_vsl.f90'
END Program
You'd need to USE both vsl_type and vsl modules. The reason is that the derived types in vsl are defined in vsl_type. MWE
Program INCL
use mkl_vsl_type
use mkl
IMPLICIT NONE
write(6, *) 'hello world'
END Program
You would need to pass the address to file mkl_vsl.f90 to ifort and the mkl flag.
ifort -mkl foo.f90 <address>/mkl_vsl.f90
For using any specific subroutine of MKL consult their website. There is also extensive examples that come with MKL. You may find it in C:/Program Files (x86)/IntelSWTools/compilers_and_libraries_2016.1.146/windows/mkl/examples or something like that.
I've tried to get an audio library statically linked to my program. I use this nimble package. To get it run, i had to build the soloud library as described here. For short after download i ran "genie --with-miniaudio-only --platform=x64 vs2017" in the "build" folder and got the source code to generate the dynamic and the static library. For now i can run the following demo program from the nimble package with the generated dll alongside:
import solouddotnim, times, os
var i, spin = 0
var sl : ptr Soloud
sl = Soloud_create()
discard Soloud_init(sl)
Soloud_setGlobalVolume(sl, 1)
var stream = WavStream_create()
discard WavStream_load(cast[ptr Wav](stream), "test.ogg")
let currentTime = epochTime()
let length = WavStream_getLength(stream)
discard Soloud_play(cast[ptr Soloud](sl), cast[ptr Wav](stream))
while epochTime() - currentTime <= length:
sleep(100)
Soloud_deinit(sl)
Soloud_destroy(sl)
Now to the static-link part. In the solouddotnim.nim file of the nimble package i use, i see this part:
when defined(windows):
const
libname* = "libsoloud.dll"
elif ...
So i simple changed the windows part to the following, re-installed the nimble-package and placed the "soloud_static_x64.lib" alongside to the "main.nim" of the testproject:
when defined(windows):
const
libname* = "soloud_static_x64.lib"
elif ...
But this doesent make it. (cant open "soloud_static_x64.lib" error when build)
Evereywhere where the constant "libname" is used there are the pragmas "cdecl", "importc" and "dynlib". For example:
proc Soloud_create*(): ptr Soloud {.cdecl, importc: "Soloud_create", dynlib: libname.}
So "dynlib" is telling nim to use a dll on windows. But was is the pragma for static libraries?
In the nim documentations i only found DynlibOverride to link to static libraries, but i dont understand the example and here is where i stuck. I've tried the followings:
nim c --dynlibOverride:libname --passL:soloud_static_x64.lib "examples\00-ogg\Example00_ogg.nim"
nim c --dynlibOverride:soloudtotnim --passL:soloud_static_x64.lib "examples\00-ogg\Example00_ogg.nim"
Firstly i dont know what parameter dynlibOverride expects and secondly both compiles, but dont work. It expects a dynamic library alongside the exe.
My last try was to remove all dynlib pragmas from the nimble package. But now i cant compile it.
undefined reference to `Soloud_create'
...
Error: execution of an external program failed: 'gcc.exe...
My knowlege ends here. Can someone help me?
Thanks in advance.
Edit:
I could not get any of your solutions work. I break down the problem as small as possible so everybody can reproduce this:
"foo.nim" contains this:
proc add*(a, b: int): int {.cdecl, exportc.} =
a + b
proc sub*(a, b: int): int {.cdecl, exportc.} =
a - b
The .lib is simply generated with this command: "nim c --app:staticlib foo.nim"
Now to use it i created a file "main.nim" with this content:
{.passL:"foo.lib".}
proc add*(a, b: int):int {.cdecl, importc.}
proc sub*(a, b: int):int {.cdecl, importc.}
echo add(10, 5)
echo sub(10, 5)
if i simply build it with "nim c -r main.nim", i get the following output and error:
P:\Nim\LearnCBinding>nim c -r main.nim
Hint: used config file 'C:\nim-1.5.1\config\nim.cfg' [Conf]
Hint: used config file 'C:\nim-1.5.1\config\config.nims' [Conf]
....CC: stdlib_io.nim
CC: stdlib_system.nim
CC: main.nim
Hint: [Link]
foo.lib(#mfoo.nim.c.o):#mfoo.nim.c:(.text+0x1f6): multiple definition of `PreMainInner'
C:\Users\Peter\nimcache\main_d\#mmain.nim.c.o:#mmain.nim.c:(.text+0x120): first defined here
foo.lib(#mfoo.nim.c.o):#mfoo.nim.c:(.text+0x20a): multiple definition of `PreMain'
C:\Users\Peter\nimcache\main_d\#mmain.nim.c.o:#mmain.nim.c:(.text+0x134): first defined here
foo.lib(#mfoo.nim.c.o):#mfoo.nim.c:(.text+0x240): multiple definition of `NimMainInner'
C:\Users\Peter\nimcache\main_d\#mmain.nim.c.o:#mmain.nim.c:(.text+0x16f): first defined here
foo.lib(#mfoo.nim.c.o):#mfoo.nim.c:(.text+0x254): multiple definition of `NimMain'
C:\Users\Peter\nimcache\main_d\#mmain.nim.c.o:#mmain.nim.c:(.text+0x183): first defined here
foo.lib(#mfoo.nim.c.o):#mfoo.nim.c:(.text+0x285): multiple definition of `main'
C:\Users\Peter\nimcache\main_d\#mmain.nim.c.o:#mmain.nim.c:(.text+0x1b4): first defined here
foo.lib(#mfoo.nim.c.o):#mfoo.nim.c:(.text+0x2da): multiple definition of `NimMainModule'
C:\Users\Peter\nimcache\main_d\#mmain.nim.c.o:#mmain.nim.c:(.text+0x209): first defined here
collect2.exe: error: ld returned 1 exit status
Error: execution of an external program failed: 'C:\nim-1.5.1\dist\mingw64\bin\gcc.exe -o P:\Nim\LearnCBinding\main.exe C:\Users\Peter\nimcache\main_d\stdlib_io.nim.c.o C:\Users\Peter\nimcache\main_d\stdlib_system.nim.c.o C:\Users\Peter\nimcache\main_d\#mmain.nim.c.o foo.lib '
Because of the multiple definition error i also tried to build foo.lib with parameter "--noMain:on", but it doesnt make any difference.
Do you have the same problem? By the way i use the current version of Nim "nim-1.5.1" and reinstalled MingW with the finish.exe from nim.
I will try to help you with the following error you have:
undefined reference to `Soloud_create'
but i will assume that you have configured your environment so you can compile your nim programs with visual studio compiler (by adding --cc:vcc to your compile command)
this is because you already seem to have visual studio 2017 and you are compiling soloud static library with it. I think this is the best option when you are compiling with one compiler both: static library and executable that will use it.
open your static library (soloud_static_x64.lib) with some text/hex editor and search for "Soloud_create". i guess you will not find anything. so why is that? because for some reason author decided to not include "C interfacing" in a static library project. so it contains only C++ symbols and not pure C symbols that are needed for our solouddotnim.nim module.
let's try to find out what .cpp file we need for that. i noticed this information on official web site of Soloud - http://sol.gfxile.net/soloud/c_api.html
so i guess we need only one file: soloud_c.cpp
let's try to just include it in SoloudStatic.vcxproj file generated by you with Genie. like this:
..
<ClCompile Include="..\..\src\c_api\soloud_c.cpp">
</ClCompile>
..
and recompile our static library. i use this command in powershell:
& 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\MSBuild\Current\Bin\MSBuild.exe' /p:PlatformToolset=v142`;WindowsTargetPlatformVersion=10`;Configuration=Release`;Platform=x64 .\SoloudStatic.vcxproj
but you can compile how you want. just make sure that it's architecture is really x64. you can check it with this command:
dumpbin /headers soloud_static_x64.lib | more
finally just link it with your nim file. add this line to the top:
{.link:"soloud_static_x64.lib".}
and compile nim file with this command:
nim c --cc:vcc --dynlibOverride:libsoloud.dll -r "examples\00-ogg\Example00_ogg.nim"
I'm using 64-bit gcc-4.8.2 to generate a 32-bit target, and my machine is 64-bit. I'm using c++11 concurrency features such as thread, mutex, conditiona_variables and etc.
The linker gave the above error message when trying to link the executable. libMyLib is also part of the project.
libMyLib.so: undefined reference to '__gthrw___pthread_key_create(unsigned int*, void (*)(void*))
nm libMyLib.so | grep pthread_key_create shows:
U _ZL28__gthrw___pthread_key_createPjPFvPvE
w __pthread_key_create##GLIBC_2.0
where is the symbol 'ghtrw___pthread_key_create' from? I tried adding '-lpthread(-pthread)' as compiler flag, but it does not help.
More information. nm libMyLib.so | grep pthread shows other symbols such as _ZL20__gthread_mutex_lockP15pthread_mutex_t is defined
where is the symbol 'ghtrw___pthread_key_create' from?
It is defined in GCC's "gthreads" abstraction layer for thread primitives, in the gthr-posix.h header.
#if SUPPORTS_WEAK && GTHREAD_USE_WEAK
# ifndef __gthrw_pragma
# define __gthrw_pragma(pragma)
# endif
# define __gthrw2(name,name2,type) \
static __typeof(type) name __attribute__ ((__weakref__(#name2))); \
__gthrw_pragma(weak type)
# define __gthrw_(name) __gthrw_ ## name
#else
# define __gthrw2(name,name2,type)
# define __gthrw_(name) name
#endif
/* Typically, __gthrw_foo is a weak reference to symbol foo. */
#define __gthrw(name) __gthrw2(__gthrw_ ## name,name,name)
...
#ifdef __GLIBC__
__gthrw2(__gthrw_(__pthread_key_create),
__pthread_key_create,
pthread_key_create)
After preprocessing that expands to:
static __typeof(pthread_key_create) __gthrw___pthread_key_create __attribute__ ((__weakref__("__pthread_key_create")));
It is supposed to be a weak reference to __pthread_key_create, so it should never have a definition, because it is just a reference to glibc's internal __pthread_key_create symbol.
So it looks like something has gone wrong with how you build you library. You should not have an undefined weak symbol.
I recently stumbled into this error, and not because of a missing -pthread.
The situation happened in a somewhat unusual setup: I was compiling a software written in C++14 under Centos7. Since C++14 requires a recent version of GCC, I relied on devtoolset 6 for it.
Given the specific setup, I opened a thread on the Centos mailing list, so I'm directly referencing the relevant thread. See https://lists.centos.org/pipermail/centos-devel/2018-May/016701.html and https://lists.centos.org/pipermail/centos-devel/2018-June/016727.html
In short, it might be caused by some bug in the preprocessor macros, either of glibc or libgcc. It can be fixed by placing #include <thread> in the beginning of the source code which gives problems once compiled. Yes, even if you don't use std::thread in it.
I don't claim this will work for everyone, but it might do the job in some particular situations.
I created simple application, which uses sqlite3 as it's datastore back-end. I faced no problems when building and running it on Linux, but after I tried to build it on Windows, I see weird linking error:
Linking dist\build\hnotes\hnotes.exe ...
C:\Documents and Settings\Admin\Application Data\cabal\sqlite-0.5.2.2\ghc-7.0.4/libHSsqlite-0.5.2.2.
a(sqlite3-local.o):sqlite3-local.c:(.text+0x21): undefined reference to `sqlite3_temp_directory'
C:\Documents and Settings\Admin\Application Data\cabal\sqlite-0.5.2.2\ghc-7.0.4/libHSsqlite-0.5.2.2.
a(sqlite3-local.o):sqlite3-local.c:(.text+0x40): undefined reference to `sqlite3_temp_directory'
collect2: v ld 1
cabal.EXE: Error: some packages failed to install:
hnotes-0.1 failed during the building phase. The exception was:
ExitFailure 1
What may be wrong there? I suspect that qalite3.dll has to be added to linking stage, but have no idea how to do that. Adding --extra-lib-dirs=path-to-sqlite-dll doesn't help either (perhaps because I need to update my cabal file somehow, to support this?).
Not sure if It's a bug or not, but the error comes from the sqlite3.h include of the sqlite package.
A look in the file shows this
/*
** CAPI3REF: Name Of The Folder Holding Temporary Files {H10310} <S20000>
**
** If this global variable is made to point to a string which is
** the name of a folder (a.k.a. directory), then all temporary files
** created by SQLite will be placed in that directory. If this variable
** is a NULL pointer, then SQLite performs a search for an appropriate
** temporary file directory.
**
** It is not safe to modify this variable once a [database connection]
** has been opened. It is intended that this variable be set once
** as part of process initialization and before any SQLite interface
** routines have been call and remain unchanged thereafter.
*/
SQLITE_EXTERN char *sqlite3_temp_directory;
so it's declared as an extern. So simple test:
module Main where
import Database.SQLite
main
= do hwd <- openConnection "test"
closeConnection hwd
putStrLn "done"
This crashes during linking as expected with the error you have above.
So I created a small C test file foo.c
#include "sqlite-0.5.2.2\\include\\sqlite3-local.h"
char* sqlite3_temp_directory = "C:\\test2";
So I'm defining a temp_directory and then I pass the c file along during compilation of the haskell source
$ ghc test.hs foo.c
[1 of 1] Compiling Main ( test.hs, test.o )
Linking test.exe ...
and then running it also returns the expected result
$ ./test
done
So it seems that you just need to give a value for the sqlite3_temp_directory, which if you set it to a NULL pointer will use the TMP/TEMP etc variables as defined in the SQLLITE manual.
edit, follow up on why it worked on Linux but not on windows
In the sqlite package, there's a file sqlite3.c under the folder sqlite3.6. This provides a bunch of defaults for the sqlite package.
when on linux OS_UNIX is defined and when on linux it uses the defines under OS_WIN.
The function we're interested in is the function which sets the temporary directory. for unix this'll be unixGetTempname and for windows winGetTempname.
If you look at the implementation of both these functions, for the unix one it has list of directories that it'll try
static const char *azDirs[] = {
0,
"/var/tmp",
"/usr/tmp",
"/tmp",
".",
};
it tries to access them in order and the one it can write to it uses to generate a temporary folder in.
For windows however one of the first lines are:
if( sqlite3_temp_directory ){
sqlite3_snprintf(MAX_PATH-30, zTempPath, "%s", sqlite3_temp_directory);
}else if( isNT() ){
so for windows sqlite3_temp_directory is actually used. This is why it doesn't compile if It can't find it.
I'm trying to create a shared library from Haskell source code.
I've tried following the instruction here: http://weblog.haskell.cz/pivnik/building-a-shared-library-in-haskell/ but I'm just not having any luck.
When I compile with Haskell 64-bit (ghc 7.0.4 from 2011.4.0.0) I get the following error:
ld: pointer in read-only segment not allowed in slidable image, used in
___gmpn_modexact_1c_odd
As an alternative I also tried the 32-bit version, and depending on the exact flags I use to link get errors such as:
Library not loaded: /usr/local/lib/ghc-7.0.4/base-4.3.1.0/libHSbase-4.3.1.0-ghc7.0.4.dylib
I did manage to get a little further by adding -lHSrts to the linker line. This got me to the point of successfully linking and loading the library, but I'm then unable to find the function name using dlsym (or manually using nm | grep)
Any hints would be greatly appreciated, an example make file, or build line that has successfully built (and used) a shared library on OS X would be appreciated. I'm quite new to Haskell and don't know if I should keep banging my head assuming that the problem is on my end, or for various reasons I shouldn't expect this to work on OS X.
A git repo with all the combinations I've tried is available here: https://github.com/bennoleslie/haskell-shared-example I did manage to get something working for 32-bit ghc, but not 64-bit yet.
It is possible to create working shared libraries on 64-bit OS X, with the latest Haskell Platform release (2012.4 64bit)
The invocation line works for me:
ghc -O2 --make \
-no-hs-main -optl '-shared' -optc '-DMODULE=Test' \
-o libTest.so Test.hs module_init.c
module_init.c should be something like:
#define CAT(a,b) XCAT(a,b)
#define XCAT(a,b) a ## b
#define STR(a) XSTR(a)
#define XSTR(a) #a
#include <HsFFI.h>
extern void CAT(__stginit_, MODULE)(void);
static void library_init(void) __attribute__((constructor));
static void library_init(void)
{
/* This seems to be a no-op, but it makes the GHCRTS envvar work. */
static char *argv[] = { STR(MODULE) ".so", 0 }, **argv_ = argv;
static int argc = 1;
hs_init(&argc, &argv_);
hs_add_root(CAT(__stginit_, MODULE));
}
static void library_exit(void) __attribute__((destructor));
static void library_exit(void)
{
hs_exit();
}
This git repo: https://github.com/bennoleslie/haskell-shared-example contains a working example.
All credit goes to this original source: http://weblog.haskell.cz/pivnik/building-a-shared-library-in-haskell/
You might want to try the ghc port in Homebrew -- https://github.com/mxcl/homebrew/blob/master/Library/Formula/ghc.rb