lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Hi,

I haven´t got any luck on finding the conflict, but for now I'm sticking with the contour solution - it solves the problem.

A doubt: is there any bindings for MS Access (DAO/JET) or MS SQLServer (OLEDB) to lua (I mean, without ODBC)?

Other doubt: why there is no support for connection strings on the ODBC provider for luasql? I tried but it only worked with DSNs.

Fabio Mascarenhas escreveu:
This definitely has the smell of a runtime conflict. You already said that you are compiling everything with MingW (Lua and libraries), are you compiling Lua as an .so, and compiling the modules against it?

As an aside, Lua and all its modules work just fine with Microsoft's C compiler (which you can download for free as part of Visual C++ Express), the Kepler project even has binaries for Lua and most of the modules (and they play nice with your compiled modules as long as you compile against the same .lib the Kepler modules use, the LuaBinaries .lib). Maybe you should check this out.

--
Fabio Mascarenhas

On 6/11/07, Luís Santos < lsantos@itquality.com.br> wrote:
New clues! It worked (sort of): it has something to do with the use of lua stack.. when I use a non-empty table as a reference to pass into cur_fetch it works well.. if the table is empty all hell break lose.
..
    row = cur:fetch ({ test="test" }, "n") -- returns values correctly
    row = cur:fetch ({ }, "n")                 -- access violation
..

On the source code, all seems right.. the table passed as a parameter is in stack index 2 when the following line runs:
ls_sqlite3.c: 153         lua_rawset(L, 2);

If this table is empty, this like violates memory - I can´t figure out why.. same for numeric indexes (ls_sqlite3.c: 141).

Luís Santos escreveu:
Yes.. I tried to compile it with GCC and I got a lot of linking errors.. then I changed $(CC) to $(CXX) - that´s g++ - and finaly it worked out. The colateral effect was that my DLL got all functions mangled (C++ style) and the Lua require engine couldn't find the luaopen_ routine.. when I discovered that was the problem, I included a #IFDEF __cplusplus directive to add an export "C" to the function - the same way sqlite3 does.

Here goes my modified makefile:

#---------------------------------------------------
#config
#---------------------------------------------------
# Driver (leave uncommented ONLY the line with the name of the driver)
#T= mysql
#T= oci8
#T= odbc
#T= postgres
#T= sqlite
T=sqlite3

# Installation directories
# System's libraries directory (where binary libraries are installed)
LUA_LIBDIR= dependencies/org.lua.engine/lib
# System's lua directory (where Lua libraries are installed)
LUA_DIR= dependencies/org.lua.engine/lib
# Lua includes directory
LUA_INC= dependencies/org.lua.engine
/include

# Lua version number (first and second digits of target version)
LUA_VERSION_NUM= 501

# OS dependent
#LIB_OPTION= -shared #for Linux
LIB_OPTION= #-bundle -undefined dynamic_lookup #for MacOS X

LIBNAME= $T.so
COMPAT_DIR= ../compat-5.1r5

# Compilation parameters
# Driver specific
######## MySQL
#DRIVER_LIBS= -L/usr/local/mysql/lib -lmysqlclient -lz
#DRIVER_INCS= -I/usr/local/mysql/include
######## Oracle OCI8
#DRIVER_LIBS= -L/home/oracle/OraHome1/lib -lz -lclntsh
#DRIVER_INCS= -I/home/oracle/OraHome1/rdbms/demo -I/home/oracle/OraHome1/rdbms/public
######## PostgreSQL
#DRIVER_LIBS= -L/usr/local/pgsql/lib -lpq
#DRIVER_INCS= -I/usr/local/pgsql/include
######## SQLite
#DRIVER_LIBS= -lsqlite
#DRIVER_INCS=
######## SQLite3
DRIVER_LIBS= -Ldependencies/org.sqlite.engine/lib -lsqlite3
DRIVER_INCS= -Idependencies/org.sqlite.engine/include
######## ODBC
#DRIVER_LIBS= -L/usr/local/lib -lodbc
#DRIVER_INCS= -DUNIXODBC -I/usr/local/include

WARN= -Wall #-Wmissing-prototypes -Wmissing-declarations -ansi
INCS= -I$(LUA_INC)
CFLAGS= -O2 $(WARN) -I$(COMPAT_DIR) $(DRIVER_INCS) $(INCS) $(DEFS)
CC= g++

# $Id: config,v 1.6 2007/04/06 23:46:04 mascarenhas Exp $


#---------------------------------------------------
#makefile
#-----------------------------
----------------------
V= 2.0.3

CONFIG= ./config

include $(CONFIG)

ifeq "$(LUA_VERSION_NUM)" "500"
COMPAT_O= $(COMPAT_DIR)/compat-5.1.o
endif

OBJS= src/luasql.o src/ls_$T.o $(COMPAT_O)


SRCS= src/luasql.h src/luasql.c \
    src/ls_postgres.c \
    src/ls_odbc.c \
    src/ls_oci8.c \
    src/ls_mysql.c \
    src/ls_sqlite.c

AR= ar rcu
RANLIB= ranlib


lib: src/$(LIBNAME)

src/$(LIBNAME): $(OBJS)
    export MACOSX_DEPLOYMENT_TARGET="10.3"; $(CC) $(CFLAGS) -o $@ $(LIB_OPTION) $(OBJS) $(DRIVER_LIBS)

$(COMPAT_DIR)/compat-5.1.o: $(COMPAT_DIR)/compat-5.1.c
    $(CC) -c $(CFLAGS) -o $@ $(COMPAT_DIR)/compat-5.1.c


dll: $T.dll

$T.exp: src/$T.def
    echo ------------------------------
    echo Generating Definitions - $@
    echo ------------------------------
    dlltool --def src/$T.def --dllname $T.dll --output-exp $T.exp --output-lib $T.a

$T.dll: $(OBJS) $T.exp
    echo ------------------------------
    echo Assembling DLL - $@
    echo ------------------------------
    $(CC) -shared -o $T.dll $(LIB_OPTION) $T.exp  $(OBJS)  -L$(LUA_LIBDIR) -llua $(DRIVER_LIBS) -Wall  -Wl,--out-implib,$T.a
    strip $T.dll
   

install:
    mkdir -p $(LUA_LIBDIR)/luasql
    cp src/$(LIBNAME) $(LUA_LIBDIR)/luasql

jdbc_driver:
    cd src/jdbc; make $@

clean:
    rm -f src/$(LIBNAME) src/*.o $(COMPAT_O)

# $Id: Makefile,v 1.52 2007/04/06 23:46:04 mascarenhas Exp $

Aditionally, I have folowed the problem into the C file, and cornered the Access Violation exactly in the loop to get the values in the cur_fetch() function. It expodes on either numeric and string keys, in the very first field. Value is obtained ok from sqlite (I log it to disk) but something went wrong in the rawset() function.

I am beginning to run out of clues.. but I will poke it a little more.. :-)


Fabio Mascarenhas escreveu:
This is strange indeed, LuaSQL is a C file so should not need to 'export "C"' anything... can you send a script of your build commands, so I can try to replicate your build? Also try to run under gdb (or even better, valgrind) to see if it sheds some light on why it barfs.

--
Fabio Mascarenhas

On 6/11/07, Luís Santos <lsantos@itquality.com.br > wrote:
I have compiled every library and binary with my G++ 3.4.2 (MinGW Edition)..
The only thing I believe to be strange here is that it seems that luasql wasn´t prepared to compile under G++ (I needed to add some const char casts and an 'export "C" for luaopen_*')

Fabio Mascarenhas escreveu:
Did you compile Lua on your own, or are you using someone else's binaries? What about other modules? Your problem looks like mixup of different C runtimes.

--
Fabio Mascarenhas



--
Luís Eduardo Jason Santos
Coordenador Técnico
IT Quality Systems
lsantos@itquality.com.br
[21]2242-7959 ramal 49



--
Luís Eduardo Jason Santos
Coordenador Técnico
IT Quality Systems
lsantos@itquality.com.br
[21]2242-7959 ramal 49




 

--
Luís Eduardo Jason Santos
Coordenador Técnico
IT Quality Systems
lsantos@itquality.com.br
[21]2242-7959 ramal 49