I am having trouble linking to the libpng library.
The build seems unable to define references to Libpng calls.
I think the problem is in my Libpng install.
I am runing in the Mingw environment on a Win7 laptop
My build environment is as follows:
My path starts with C:\MinGW\bin;C:\MinGW\msys\1.0\bin;C:\MinGW\git\cmd;C:\Program Files
C:\Users\Bob\Home\png23d>g++ --version
g++ (GCC) 5.3.0
I have built and installed libpng-1.6.28 which creates the following:
C:\MinGW\bin>
libpng-config
libpng16-config
libpng16.dll
C:\MinGW\include\libpng
png.h
pngconf.h
pnglibconf.h
C:\MinGW\include\libpng16
png.h
pngconf.h
pnglibconf.h
C:\MinGW\lib\pkgconfig
C:\MinGW\lib>
libpng.a
libpng.dll.a
libpng16.a
libpng16.dll.a
a symbolic link `libpng' to `libpng16'
a symbolic link `libpng.pc' to `libpng16.pc'
a symbolic link `libpng.a' to `libpng16.a'
a symbolic link `libpng-config' to `libpng16-config
when I try to build a program "png23d" I get the following
C:\Users\Bob\Home\png23d>make
g++ -DUSE_LIBPNG -lpng png23d.o option.o bitmap.o mesh.o mesh_gen.o mesh_index.o mesh_simplify.o out_pgm.o out_rscad.o out_pscad.o out_stl.o -o png23d
bitmap.o:bitmap.c:(.text+0x102): undefined reference to `png_sig_cmp'
bitmap.o:bitmap.c:(.text+0x142): undefined reference to `png_create_read_struct'
.
.
.
bitmap.o:bitmap.c:(.text+0x418): undefined reference to `png_read_end'
bitmap.o:bitmap.c:(.text+0x466): undefined reference to `png_destroy_read_struct'
collect2.exe: error: ld returned 1 exit status
<builtin>: recipe for target 'png23d' failed
make: *** [png23d] Error 1
I am almost sure its the -lpng that is not working.... I am just don't know how to fix it.
I am guessing that it is a symbolic link problem and I know I did not create one during the libpng build.
If I am right what do I need to link it to.
I tried changing -lpng to -llpng16. It made no difference.
Thanks from the command prompt that work fine.
just have to figure out how to change the make file.
#!/usr/bin/make
#
# png23d is a program to convert png images into 3d files
#
# Copyright 2011 Vincent Sanders <vince#kyllikki.org>
#
# Released under the MIT License,
# http://www.opensource.org/licenses/mit-license.php
CC = g++
VERSION=100
PREFIX =
WARNFLAGS = -W -Wall -Wundef -Wpointer-arith \
-Wcast-align -Wwrite-strings -Wstrict-prototypes \
-Wmissing-prototypes -Wmissing-declarations -Wredundant-decls \
-Wnested-externs
ifneq ($(GCCVER),2)
WARNFLAGS += -Wno-unused-parameter
endif
OPTFLAGS=-O2
#OPTFLAGS=-O0
CFLAGS+=$(WARNFLAGS) -MMD -DVERSION=$(VERSION) $(OPTFLAGS) -g
LDFLAGS+= -DUSE_LIBPNG -lpng
PNG23D_OBJ=png23d.o option.o bitmap.o mesh.o mesh_gen.o mesh_index.o mesh_simplify.o out_pgm.o out_rscad.o out_pscad.o out_stl.o
.PHONY : all clean
all:png23d
png23d:$(PNG23D_OBJ)
-include $(PNG23D_OBJ:.o=.d)
-include test/Makefile.sub
clean: testclean
${RM} png23d $(PNG23D_OBJ) *.d *~ png23d.png
install:png23d
install -D png23d $(DESTDIR)$(PREFIX)/bin
install-man:png23d.1
install -D png23d.1 $(DESTDIR)$(PREFIX)/share/man/man1
# logo creation
png23d.png:png23d.pov
povray +L/usr/share/povray/include/ -D +Q11 +O$# +UV +UL +A0.2 +FP8 +W400 +H300 $<
Move -lpng to after the object files.
Related
I'm trying to compile my patched dwm on Debian.
This is my config.mk file, it's mostly the one from apt source dwm but the patches added some extra libraries, and I had to add the two -Ifreetype2 links myself:
# dwm version
VERSION = 6.1
# Customize below to fit your system
# paths
PREFIX = /usr/local
MANPREFIX = ${PREFIX}/share/man
# Xinerama, comment if you don't want it
XINERAMALIBS = -lXinerama
XINERAMAFLAGS = -DXINERAMA
# freetype
FREETYPELIBS = -lfontconfig -lXft
FREETYPEINC = /usr/include/freetype2
# OpenBSD (uncomment)
#FREETYPEINC = ${X11INC}/freetype2
# includes and libs
INCS = -I${X11INC} -I${FREETYPEINC} -I/usr/include/freetype2 -I/usr/include/libpng16
LIBS = -L${X11LIB} -lX11 ${XINERAMALIBS} ${FREETYPELIBS} -lXrender -lX11-xcb -lxcb -lxcb-res
# flags
CPPFLAGS += -D_BSD_SOURCE -D_POSIX_C_SOURCE=2 -DVERSION=\"${VERSION}\" ${XINERAMAFLAGS}
#CFLAGS = -g -std=c99 -pedantic -Wall -O0 ${INCS} ${CPPFLAGS}
CFLAGS += -std=c99 -pedantic -Wall -Wno-deprecated-declarations ${INCS} ${CPPFLAGS}
LDFLAGS += -s ${LIBS}
# Solaris
#CFLAGS = -fast ${INCS} -DVERSION=\"${VERSION}\"
#LDFLAGS = ${LIBS}
# compiler and linker
CC = cc
This is the error I get when running make clean install
cc -o dwm drw.o dwm.o util.o -s -L -lX11 -lXinerama -lfontconfig -lXft -lXrender -lX11-xcb -lxcb -lxcb-res
/usr/bin/ld: dwm.o: undefined reference to symbol 'XMapSubwindows'
/usr/bin/ld: //lib/x86_64-linux-gnu/libX11.so.6: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make: *** [Makefile:29: dwm] Error 1
But I have no idea how to fix this. Do I need a library installed? do I need to add somthing to the libs variable? please help!
I have tried looking at this, but I have no idea what a "DSO" is, nor how to fix the linkage.
Not sure if it's the only problem but your link line...
cc -o dwm drw.o dwm.o util.o -s -L -lX11 -lXinerama -lfontconfig -lXft -lXrender -lX11-xcb -lxcb -lxcb-res
appears to have a -L option with no parameter. Or, perhaps more correctly, it will assume that its parameter is -lX11. I'm assuming this is because the variable X11LIB is unspecified in your makefile. Not sure exactly how X11LIB is supposed to be specified with the makefile you're using but you could try setting it explicitly...
X11LIB := /usr/lib64 # Assumes the path to libX11.so is /usr/lib64/libX11.so
-L -lX11
This means "add a directory named -lX11 to the library search path". This is unlikely to have any effect as such directory probably does nit exist.
Remove -L or add a non-empty directory argument after it.
I'm working on a Linux project in C consisting of two different open source applications. "Project A" (libduo) creates an archive used for linking a couple test programs and creates the library like this:
/usr/bin/ar rv libduo.a duo.o http_parser.o https.o match.o parson.o urlenc.o
/usr/bin/ar: creating libduo.a
a - duo.o
a - http_parser.o
a - https.o
a - match.o
a - parson.o
a - urlenc.o
ranlib libduo.a
One of the libduo test programs is built like this:
gcc -g -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -I. -I. -DDUODIR=\"/usr/local/duo/libduo/etc\" -DHAVE_CONFIG_H -c test-duologin.c
gcc -o test-duologin test-duologin.o -L. -lduo -lssl -lcrypto
"Project B" is an OpenLDAP module which I've built with -lduo and a few options to tell it where to find things:
(cd .libs && rm -f pw-apr1.la && ln -s ../pw-apr1.la pw-apr1.la)
../../../libtool --mode=compile gcc -g -O2 -Wall -I../../../include -I../../../include -I../../../servers/slapd -I../../../contrib/slapd-modules/passwd/libduo -c pw-duo.c
gcc -g -O2 -Wall -I../../../include -I../../../include -I../../../servers/slapd -I../../../contrib/slapd-modules/passwd/libduo -c pw-duo.c -fPIC -DPIC -o .libs/pw-duo.o
gcc -g -O2 -Wall -I../../../include -I../../../include -I../../../servers/slapd -I../../../contrib/slapd-modules/passwd/libduo -c pw-duo.c -o pw-duo.o >/dev/null 2>&1
../../../libtool --mode=link gcc -g -O2 -Wall -version-info 0:0:0 \
-rpath /usr/local/libexec/openldap -module -o pw-duo.la pw-duo.lo libduo.a -lduo
*** Warning: Linking the shared library pw-duo.la against the
*** static library libduo.a is not portable!
cc -shared .libs/pw-duo.o libduo.a -lduo -Wl,-soname -Wl,pw-duo.so.0 -o .libs/pw-duo.so.0.0.0
/usr/bin/ld: libduo.a(duo.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
libduo.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Makefile:51: recipe for target 'pw-duo.la' failed
make: *** [pw-duo.la] Error 1
The Makefile I'm using is the same one distributed with the OpenLDAP project. I've just added a section in the Makefile to build my module, using the same options for the other modules already there but adding -lduo to my section along with the paths to the libduo includes and libduo.a.
As make suggests above, I've recompiled by adding -fPIC after the -Wall option but it the same error was repeated. As a last resort, I tried adding -static to the module build but make was having none of that either:
*** Warning: Linking the shared library pw-duo.la against the
*** static library libduo.a is not portable!
This is the first time I've tried to build a C application against a lib not in the standard Linux locations so not exactly sure what's going on. I suspect libduo is built intended to be statically linked into everything, but the OpenLDAP modules are designed to use shared libraries. Can anyone elucidate?
Update: with help of comments below and this link I created a shared library from the .o files and distributed/built against that.
I am trying to move a program from my cloud9-ide to my raspberry. But when I move them the makefile no longer works.
#
# Makefile
#
# Computer Science 50
# Problem Set 5
#
# compiler to use
CC = clang
# flags to pass compiler
CFLAGS = -ggdb3 -O0 -Qunused-arguments -std=c11 -Wall -Werror
# name for executable
EXE = myTest
# space-separated list of header files
HDRS = i2cContinuousRead.h
# space-separated list of libraries, if any,
# each of which should be prefixed with -l
LIBS =
# space-separated list of source files
SRCS = myTest.c i2cContinuousRead.c
# automatically generated list of object files
OBJS = $(SRCS:.c=.o)
# default target
$(EXE): $(OBJS) $(HDRS) Makefile
$(CC) $(CFLAGS) -o $# $(OBJS) $(LIBS)
# dependencies
$(OBJS): $(HDRS) Makefile
# housekeeping
clean:
rm -f core $(EXE) *.o
I get the error output
clang -ggdb3 -Qunused-arguments -std=c11 -Wall -Werror -c -o myTest.o myTest.c
make: clang: Command not found
<builtin>: recipe for target 'myTest.o' failed
make: *** [myTest.o] Error 127
I tried to update sudo apt-get install build-essential
I have a fresh install if jessy.
Any tips?
Not sure why you're compiling with clang, but letting CC = gcc in makefile let you compile your application with gcc, but if you really need clang, you can install it with
sudo apt-get install clang llvm
It seems you haven't installed clang on your system. You can install it as suggested by e.jahandar or use the standard gcc compiler shipped with the linux distro jessy.
I've been having trouble debugging some C code that I'm writing as part of an R package. The code compiles and executes when I use R CMD SHLIB from the Windows console (i.e. cmd.exe):
>R CMD SHLIB MaximumAgreementForest.c
gcc -m64 -I"C:/PROGRA~1/R/R-32~1.4RE/include" -DNDEBUG -I"d:/RCompile/r-compiling/local/local323/include" -O2 -Wall -std=gnu99 -mtune=core2 -c MaximumAgreementForest.c -o MaximumAgreementForest.o
gcc -m64 -shared -s -static-libgcc -o MaximumAgreementForest.dll tmp.def MaximumAgreementForest.o -Ld:/RCompile/r-compiling/local/local323/lib/x64 -Ld:/RCompile/r-compiling/local/local323/lib -LC:/PROGRA~1/R/R-32~1.4RE/bin/x64 -lR
The script also built correctly in Netbeans until I started using the functions R_alloc and C_alloc from the R libraries. Now it doesn't seem to be able to find the definitions of a number of R-specific functions. When I attempt to build the project in Netbeans the console lists the following:
cd 'C:\Work\Fun\implied_weight\MAF'
C:\MinGW\msys\1.0\bin\make.exe -f Makefile CONF=Debug
"/C/MinGW/msys/1.0/bin/make.exe" -f nbproject/Makefile-Debug.mk QMAKE= SUBPROJECTS= .build-conf
make.exe[1]: Entering directory `/c/Work/Fun/implied_weight/MAF'
"/C/MinGW/msys/1.0/bin/make.exe" -f nbproject/Makefile-Debug.mk dist/Debug/MinGW-Windows/libMAF.dll
make.exe[2]: Entering directory `/c/Work/Fun/implied_weight/MAF'
mkdir -p build/Debug/MinGW-Windows/_ext/5c0
rm -f "build/Debug/MinGW-Windows/_ext/5c0/MaximumAgreementForest.o.d"
gcc -DDEBUG -O2 -Wall -mtune=core2 -c -g -Wall -I/C/Program\ Files/R/R-3.2.4revised/include -MMD -MP -MF "build/Debug/MinGW-Windows/_ext/5c0/MaximumAgreementForest.o.d" -o build/Debug/MinGW-Windows/_ext/5c0/MaximumAgreementForest.o ../MaximumAgreementForest.c
mkdir -p dist/Debug/MinGW-Windows
gcc -DDEBUG -O2 -Wall -mtune=core2 -o dist/Debug/MinGW-Windows/libMAF.dll build/Debug/MinGW-Windows/_ext/5c0/MaximumAgreementForest.o -L/C/Program\ Files/R -L/C/Program\ Files/R/R-3.2.4revised/library -shared
build/Debug/MinGW-Windows/_ext/5c0/MaximumAgreementForest.o: In function `forest_new':
C:\Work\Fun\implied_weight\MAF/../MaximumAgreementForest.c:37: undefined reference to `R_alloc'
build/Debug/MinGW-Windows/_ext/5c0/MaximumAgreementForest.o: In function `forest_plant':
C:\Work\Fun\implied_weight\MAF/../MaximumAgreementForest.c:55: undefined reference to `S_alloc'
[...]
C:\Work\Fun\implied_weight\MAF/../MaximumAgreementForest.c:515: undefined reference to `R_chk_free'
collect2.exe: error: ld returned 1 exit status
My script, a single .c file, contains the lines
#define USE_RINTERNALS
#include <R.h> // which itself #includes R_ext/Memory, R_ext Printf
#include <R_ext/Print.h>
#include <R_ext/Memory.h>
#include <Rinternals.h>
Figuring that Netbeans is failing to point to the relevant libraries, I have tried adding and removing C:/Program Files/R/R-3.2.4revised/include and C:/Program Files/R/R-3.2.4revised/bin/x64 at File→Project Properties→General→Source folders, to no effect.
Under File→Project Properties→Build→C compiler, I have included C:/Program Files/R/R-3.2.4revised/include.
When I add C:/Program Files/R/R-3.2.4revised/bin/x64/R.dll to Build→Linker→Libraries→Libraries, via the Add Library... option, I receive the error c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: cannot find -lR, and the linker exits without (before?) complaining about the undefined references.
When I subsequently add "C:/Program Files/R/R-3.2.4revised/bin/x64/", which is already in by System PATH, to Build→Linker→Additional Library Directories, the compiler fails with the message C:/Program Files/R/R-3.2.4revised/bin/x64/R.dll: file not recognized: File format not recognized
What am I missing... how can I point Netbeans to the relevant R libraries?
The File format not recognized error is encountered when a 32-bit compiler tries to load to a 64-bit .dll (or vice-versa). Changing the path
C:/Program Files/R/R-3.2.4revised/bin/x64/R.dll
to
C:/Program Files/R/R-3.2.4revised/bin/i386/R.dll
resolved the problem.
I have lua, that I isntalled using luarocks.
Edit: on a windows system
I successfully installed luasocket by downloading the luasocket-2.0.2-3.win32-x86.rock file from v202-3 from here. Its an older version, but it works.
However now I need to install yaml so I can work with yaml files. Now I am forced to install using a *.src.rock file or a .rockspec file.
I have tried:
luarocks install yaml which gives:
D:\user\workspace\_lua>luarocks install yaml
Warning: Failed searching manifest: Failed fetching manifest for https://luarocks.org - Failed downloading https://luarocks.org/manifest - C:\Users\user\AppData\Local/LuaRocks/Cache/https___luarocks.org/manifest
Warning: Failed searching manifest: Failed fetching manifest for https://raw.githubusercontent.com/rocks-moonscript-org/moonrocks-mirror/master/ - Failed downloading https://raw.githubusercontent.com/rocks-moonscript-org/moonrocks-mirror/master/manifest - C:\Users\user\AppData\Local/LuaRocks/Cache/https___raw.githubusercontent.com_rocks-moonscript-org_moonrocks-mirror_master_/manifest
Warning: Failed searching manifest: Failed fetching manifest for http://luafr.org/moonrocks/ - Failed downloading http://luafr.org/moonrocks/manifest - C:\Users\user\AppData\Local/LuaRocks/Cache/http___luafr.org_moonrocks_/manifest
Warning: Failed searching manifest: Failed fetching manifest for http://luarocks.logiceditor.com/rocks - Failed downloading http://luarocks.logiceditor.com/rocks/manifest - C:\Users\user\AppData\Local/LuaRocks/Cache/http___luarocks.logiceditor.com_rocks/manifest
Error: No results matching query were found.
So, then I downloaded yaml-1.1.2-1.src.rock and ran the command:
luarocks install yaml-1.1.2-1.src.rock
This told me that I had dependencies yaml --> lub --> luafilesystem. so then I downloaded:
luafilesystem-1.6.3-2.src.rock
lub-1.1.0-1.src.rock
yaml-1.1.2-1.src.rock
And I installed them one after the other with the result:
luarocks install luafilesystem-1.6.3-2.src.rock - OK
luarocks install lub-1.1.0-1.src.rock - OK
luarocks install yaml-1.1.2-1.src.rock - FAILED, see errors below
Error log:
D:\user\downloads\luarocks-2.3.0-win32\extras>luarocks install yaml-1.1.2-1.src.rock
Using yaml-1.1.2-1.src.rock... switching to 'build' mode
mingw32-gcc -O2 -c -o src/api.o -ID:/user/install/lua/luarocks/include src/api.c -Isrc
mingw32-gcc -O2 -c -o src/b64.o -ID:/user/install/lua/luarocks/include src/b64.c -Isrc
mingw32-gcc -O2 -c -o src/dumper.o -ID:/user/install/lua/luarocks/include src/dumper.c -Isrc
mingw32-gcc -O2 -c -o src/emitter.o -ID:/user/install/lua/luarocks/include src/emitter.c -Isrc
mingw32-gcc -O2 -c -o src/loader.o -ID:/user/install/lua/luarocks/include src/loader.c -Isrc
mingw32-gcc -O2 -c -o src/lyaml.o -ID:/user/install/lua/luarocks/include src/lyaml.c -Isrc
mingw32-gcc -O2 -c -o src/parser.o -ID:/user/install/lua/luarocks/include src/parser.c -Isrc
mingw32-gcc -O2 -c -o src/reader.o -ID:/user/install/lua/luarocks/include src/reader.c -Isrc
mingw32-gcc -O2 -c -o src/scanner.o -ID:/user/install/lua/luarocks/include src/scanner.c -Isrc
mingw32-gcc -O2 -c -o src/strtod.o -ID:/user/install/lua/luarocks/include src/strtod.c -Isrc
In file included from src/strtod.c:23:0:
src/strtod.c:24:17: warning: '_errno' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
extern int errno;
^
mingw32-gcc -O2 -c -o src/writer.o -ID:/user/install/lua/luarocks/include src/writer.c -Isrc
mingw32-gcc -shared -o yaml/core.dll src/api.o src/b64.o src/dumper.o src/emitter.o src/loader.o src/lyaml.o src/parser.o src/reader.o src/scanner.o src/strtod.o src/writer.o D:/user/install/lua/luarocks/lua5.1.lib -lMSVCR80
src/api.o:api.c:(.text+0x395): undefined reference to '_imp__yaml_realloc'
src/api.o:api.c:(.text+0x412): undefined reference to '_imp__yaml_string_extend'
:
LOTS OF THESE
:
src/scanner.o:scanner.c:(.text.unlikely+0x29d0): undefined reference to '_imp__yaml_queue_extend'
src/scanner.o:scanner.c:(.text.unlikely+0x29e8): undefined reference to '_imp__yaml_token_delete'
collect2.exe: error: ld returned 1 exit status
Error: Build error: Failed compiling module yaml/core.dll
Does anyone know why this build fails? - I got it directly from here: https://luarocks.org/modules/gaspard/yaml/1.1.2-1 which is the most downloaded version... so I guess it should work?
I mean, I can see what the error is... but I don't understand why there should be an error. How can I resolve this?... Any help appreciated :)
UPDATE
Thanks to siffiejoe's comment, I was able to compile the yaml rock. Here is the output:
D:\user\downloads\luarocks-2.3.0-win32\extras>luarocks install yaml-1.1.2-1.src.rock CC="gcc -DYAML_DECLARE_STATIC"
Using yaml-1.1.2-1.src.rock... switching to 'build' mode
gcc -DYAML_DECLARE_STATIC -O2 -c -o src/api.o -ID:/user/install/lua/luarocks/include src/api.c -Isrc
gcc -DYAML_DECLARE_STATIC -O2 -c -o src/b64.o -ID:/user/install/lua/luarocks/include src/b64.c -Isrc
gcc -DYAML_DECLARE_STATIC -O2 -c -o src/dumper.o -ID:/user/install/lua/luarocks/include src/dumper.c -Isrc
gcc -DYAML_DECLARE_STATIC -O2 -c -o src/emitter.o -ID:/user/install/lua/luarocks/include src/emitter.c -Isrc
gcc -DYAML_DECLARE_STATIC -O2 -c -o src/loader.o -ID:/user/install/lua/luarocks/include src/loader.c -Isrc
gcc -DYAML_DECLARE_STATIC -O2 -c -o src/lyaml.o -ID:/user/install/lua/luarocks/include src/lyaml.c -Isrc
gcc -DYAML_DECLARE_STATIC -O2 -c -o src/parser.o -ID:/user/install/lua/luarocks/include src/parser.c -Isrc
gcc -DYAML_DECLARE_STATIC -O2 -c -o src/reader.o -ID:/user/install/lua/luarocks/include src/reader.c -Isrc
gcc -DYAML_DECLARE_STATIC -O2 -c -o src/scanner.o -ID:/user/install/lua/luarocks/include src/scanner.c -Isrc
gcc -DYAML_DECLARE_STATIC -O2 -c -o src/strtod.o -ID:/user/install/lua/luarocks/include src/strtod.c -Isrc
In file included from src/strtod.c:23:0:
src/strtod.c:24:17: warning: '_errno' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
extern int errno;
^
gcc -DYAML_DECLARE_STATIC -O2 -c -o src/writer.o -ID:/user/install/lua/luarocks/include src/writer.c -Isrc
mingw32-gcc -shared -o yaml/core.dll src/api.o src/b64.o src/dumper.o src/emitter.o src/loader.o src/lyaml.o src/parser.o src/reader.o src/scanner.o src/strtod.o src/writer.o D:/user/install/lua/luarocks/lua5.1.lib -lMSVCR80
Updating manifest for D:\user\install\lua\luarocks\systree/lib/luarocks/rocks
yaml 1.1.2-1 is now built and installed in D:\user\install\lua\luarocks\systree (license: MIT)
So it says it is installed. However when I try to use the yaml packge it does not find it:
local yaml = require("yaml")
local data = yaml.load("mytest.yaml")
The system reports that it can't find yaml.lua or yaml.dll. I then searched *.lua and *.dll in my luarocks folder I found:
D:\user\install\lua\luarocks\systree>dir *.lua *.dll /b /s
D:\user\install\lua\luarocks\systree\lib\lua\5.1\lfs.dll
D:\user\install\lua\luarocks\systree\lib\lua\5.1\mime\core.dll
D:\user\install\lua\luarocks\systree\lib\lua\5.1\socket\core.dll
D:\user\install\lua\luarocks\systree\lib\lua\5.1\yaml\core.dll
D:\user\install\lua\luarocks\systree\lib\luarocks\rocks\luafilesystem\1.6.3-2\tests\test.lua
D:\user\install\lua\luarocks\systree\share\lua\5.1\ltn12.lua
D:\user\install\lua\luarocks\systree\share\lua\5.1\mime.lua
D:\user\install\lua\luarocks\systree\share\lua\5.1\socket.lua
D:\user\install\lua\luarocks\systree\share\lua\5.1\lub\Autoload.lua
D:\user\install\lua\luarocks\systree\share\lua\5.1\lub\Dir.lua
D:\user\install\lua\luarocks\systree\share\lua\5.1\lub\init.lua
D:\user\install\lua\luarocks\systree\share\lua\5.1\lub\Param.lua
D:\user\install\lua\luarocks\systree\share\lua\5.1\lub\Template.lua
D:\user\install\lua\luarocks\systree\share\lua\5.1\socket\ftp.lua
D:\user\install\lua\luarocks\systree\share\lua\5.1\socket\http.lua
D:\user\install\lua\luarocks\systree\share\lua\5.1\socket\smtp.lua
D:\user\install\lua\luarocks\systree\share\lua\5.1\socket\tp.lua
D:\user\install\lua\luarocks\systree\share\lua\5.1\socket\url.lua
D:\user\install\lua\luarocks\systree\share\lua\5.1\yaml\init.lua
For example, I managed to install luasocket with luarocks install luasocket-2.0.2-3.win32-x86.rock because there was a .rock file available. And so you can see there is a socket.lua. For yaml, lub and luafilesystem I can see various install locations, but there is no .lua or .dll files...
I searched more for yaml specifically:
D:\user\install\lua\luarocks\systree>dir *yaml* /b /s
D:\user\install\lua\luarocks\systree\lib\lua\5.1\yaml
D:\user\install\lua\luarocks\systree\lib\luarocks\rocks\yaml
D:\user\install\lua\luarocks\systree\lib\luarocks\rocks\yaml\1.1.2-1\yaml-1.1.2-1.rockspec
D:\user\install\lua\luarocks\systree\share\lua\5.1\yaml
ehh... so then I went and cloned the project from git (had to download the zip file because my stupid IT blocked my git clone ... (port 443).
So finally got that sorted, then in the yaml-master folder I tried:
luarocks make yaml-1.1.2-1.rockspec CC-"gcc -DYAML_DECLARE_STATIC"
This had the same effect as before. So now I have tried both .src.rock and .rockspec types...
I am stuck again :(
UPDATE 2
When I built from git, there was a file called yaml.lua in the top level. But all it contains is the text yaml/init.lua ... not sure what to do with that - tried copying it into the my ..install\lua\luarocks\systree\share\lua\5.1 dir, but when I run my test lua projam it gives an error.... what is going on, it can't be this hard to install :(
UPDATE 3
Following on from siffiejoe's great answer, I have more or less got this yaml installed. But I have a bug running it:
Here is my lua script:
package.path = "D:\\user\\install\\lua\\luarocks\\systree\\share\\lua\\5.1\\?\\init.lua;" .. package.path
print("package.path: " .. package.path)
local yaml = require("yaml")
local data = yaml.load("mytest.yaml")
I am manually adding the lua path for now while I am testing. When I run this I get the window:
And my log looks like:
D:\user\install\lua\luarocks\systree\share\lua\5.1\?\init.lua;D:\user\install\lua\luarocks\systree\share\lua\5.1\?.lua;D:\user\install\lua\luarocks\systree\share\lua\5.1\?\init.lua;./?.lua;./?/init.lua;./lua/?.lua;./lua/?/init.lua;D:\user\install\lua\zerobrane\lualibs/?/?.lua;D:\user\install\lua\zerobrane\lualibs/?.lua;D:\user\install\lua\zerobrane\lualibs/?/?/init.lua;D:\user\install\lua\zerobrane\lualibs/?/init.lua
D:\user\install\lua\zerobrane\bin\lua.exe: error loading module 'lfs' from file 'D:\user\install\lua\luarocks\systree\lib\lua\5.1\lfs.dll':
The specified procedure could not be found.
stack traceback:
[C]: at 0x66df0460
[C]: in function 'require'
...\install\lua\luarocks\systree\share\lua\5.1\lub\init.lua:17: in main chunk
[C]: in function 'require'
...install\lua\luarocks\systree\share\lua\5.1\yaml\init.lua:25: in main chunk
[C]: in function 'require'
D:\user\workspace\_lua\myluatest.lua:3: in main chunk
[C]: at 0x00402a57
Program completed in 56.64 seconds (pid: 15856).
So it appears to come back to this MSVCR80.dll ... this is not making sense to me, I assume this is do with microsoft... Some things I have read about it could be a corrupt MSVCR80.dll that needs replacing or somthing. But I am not yet sure about why this is occuring. Any thoughts?
The include file src/yaml.h from the github repository contains the following preprocessor code:
#ifdef WIN32
# if defined(YAML_DECLARE_STATIC)
# define YAML_DECLARE(type) type
# elif defined(YAML_DECLARE_EXPORT)
# define YAML_DECLARE(type) __declspec(dllexport) type
# else
# define YAML_DECLARE(type) __declspec(dllimport) type
# endif
#else
# define YAML_DECLARE(type) type
#endif
That means that on Windows all yaml-related functions by default are decorated with __declspec(dllimport) (the _imp__ prefixes in the linker error messages were hints). Because of this the linker expects those functions to be in an external DLL. But the yaml code is bundled and compiled together with the Lua binding into a single DLL yaml\core.dll, and so the linker complains. The correct way to fix this is to remove all import/export-related decorations from the yaml functions, and this can be achieved by defining YAML_DECLARE_STATIC. This macro should definitely be set in the rockspec (I'll post a bug report later), but a quick and dirty solution is to set it via the CC variable on the commandline:
luarocks install yaml-1.1.2-1.src.rock CC="mingw32-gcc -DYAML_DECLARE_STATIC"
After that there should be a yaml\core.dll file and a yaml\init.lua file somewhere in your LuaRocks directory. To use the Lua yaml binding you have to make sure that a require("yaml") loads the yaml\init.lua file, and that require("yaml.core") loads yaml\core.dll. This can be achieved by adding to package.path/package.cpath (from within your Lua script) or preferably by adding to LUA_PATH/LUA_CPATH. Since the installed LuaSocket already works, you probably have LUA_PATH/LUA_CPATH mostly set up correctly, but the yaml binding uses a different approach for loading its main Lua module than LuaSocket: LuaSocket has socket.lua for require("socket"), but yaml has yaml\init.lua for require("yaml"). This approach has the advantage that any Lua submodules (e.g. yaml.a) would be in the same directory as the code for the main Lua module. Anyway, you also have to add
D:\user\install\lua\luarocks\systree\share\lua\5.1\?\init.lua
to your LUA_PATH environment variable.
Btw., the yaml.lua file you found in the github repository is a symbolic link and won't work correctly on Windows anyway (but it could interfere, so you shouldn't put it into your rocks tree). It's only there for convenience during development.