headers
mitchell | 2 Jan 2007 07:44
Picon

loadlib

Hi,

I am trying to enable loadlib in Linux. I include the liblua.a and 
liblualib.a files in the makefile and SciTE compiles correctly and runs 
with lua working just fine, but whenever I try to load a library, (in my 
case), I get an 'undefined symbol: luaL_newmetatable' error. It appears 
the *.a files are not being correctly loaded or something. I notice 
including scintilla.a in the build process works, so why not *lua.a?

For reference, here is a relevant snippet of my gtk/makefile:

LUA_OBJS = LuaExtension.o IFaceTable.o

INCLUDEDIRS=-I ../../scintilla/include -I ../src -I../lua/include
#$(LUA_CORE_OBJS): ../lua/src/*.c
#	gcc $(INCLUDEDIRS) $(CXXTFLAGS) -c ../lua/src/*.c
#$(LUA_LIB_OBJS): ../lua/src/lib/*.c
#	gcc $(INCLUDEDIRS) $(CXXTFLAGS) -c ../lua/src/lib/*.c
CXXFLAGS=$(CXXTFLAGS)
else
CXXFLAGS=$(CXXTFLAGS) -DNO_LUA
endif

# make should be run in ../../scintilla/gtk to compile all the lexers.
COMPLIB=../../scintilla/bin/scintilla.a
LCOMPLIB=../lua/lib/liblua.a ../lua/lib/liblualib.a

$(PROG): SciTEGTK.o FilePath.o SciTEBase.o SciTEBuffers.o \
SciTEIO.o Exporters.o MultiplexExtension.o \
DirectorExtension.o SciTEProps.o Utf8_16.o $(LUA_OBJS) \
(Continue reading)

Permalink | Reply | 0 comments |
headers
mitchell | 2 Jan 2007 07:48
Picon

loadlib in linux

Hi,

Sorry if this is a double post.

I am trying to enable loadlib in Linux. I incorporate liblua.a and 
liblualib.a into the scite build and it succeeds and lua runs in 
general. However, when I try to run loadlib, I get a 'undefined symbol: 
luaL_newmetatable'. It appears the *.a files are not loading properly or 
something. The scintilla.a does of course, but why not *lua.a?

For reference, here is a relevant snippet of my gtk/makefile:

LUA_OBJS = LuaExtension.o IFaceTable.o

INCLUDEDIRS=-I ../../scintilla/include -I ../src -I../lua/include
#$(LUA_CORE_OBJS): ../lua/src/*.c
#	gcc $(INCLUDEDIRS) $(CXXTFLAGS) -c ../lua/src/*.c
#$(LUA_LIB_OBJS): ../lua/src/lib/*.c
#	gcc $(INCLUDEDIRS) $(CXXTFLAGS) -c ../lua/src/lib/*.c
CXXFLAGS=$(CXXTFLAGS)
else
CXXFLAGS=$(CXXTFLAGS) -DNO_LUA
endif

# make should be run in ../../scintilla/gtk to compile all the lexers.
COMPLIB=../../scintilla/bin/scintilla.a
LCOMPLIB=../lua/lib/liblua.a ../lua/lib/liblualib.a

$(PROG): SciTEGTK.o FilePath.o SciTEBase.o SciTEBuffers.o \
SciTEIO.o Exporters.o MultiplexExtension.o \
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Sutcliffe | 2 Jan 2007 22:30
Picon

Suppressing menu entries

Is it possible to suppress menu entries like 'Compile', 'Build' and
'Go'?  I know they are disabled when they are not viable (i.e. editing
a text file), but I was wondering if it was possible to hide them
completely.

Thanx!

Chris

--

-- 
Chris Sutcliffe
http://ir0nh34d.googlepages.com
http://ir0nh34d.blogspot.com
http://emergedesktop.org
Permalink | Reply | 2 comments |
headers
mitchell | 3 Jan 2007 00:22
Picon

Re: Suppressing menu entries

Hi,

> Is it possible to suppress menu entries like 'Compile', 'Build' and
> 'Go'?  I know they are disabled when they are not viable (i.e. editing
> a text file), but I was wondering if it was possible to hide them
> completely.

I doubt there is a way without recompiling. If you are in linux, go into 
gtk/SciTEGTK.cxx and remove or comment out the menu items; if you are in 
windows, remove them from the resource file in win32/. Then recompile.

-Mitchell;

> 
> Thanx!
> 
> Chris
>
Permalink | Reply | 0 comments |
headers
Neil Hodgson | 3 Jan 2007 00:32
Picon

Re: Suppressing menu entries

Chris Sutcliffe:

> Is it possible to suppress menu entries like 'Compile', 'Build' and
> 'Go'?  I know they are disabled when they are not viable (i.e. editing
> a text file), but I was wondering if it was possible to hide them
> completely.

   No.

   You could try removing them from the source code
(scite/gtk/SciTEGTK.cxx for GTK+ and scite/win32/SciTERes.rc on
Windows) and rebuilding but the rest of the menu is maintained based
on positions (and removing these changes all the positions) so you
should also modify TOOLS_START in scite/src/SciTE.h. There may be
other issues: this isn't a change that fits in easy.

   Neil
Permalink | Reply | 0 comments |
headers
Neil Hodgson | 3 Jan 2007 02:58
Picon

Version 1.72 in about a week

   I'm thinking of making a 1.72 release in around a week from now. If
you have something you want included send it real soon.

   Windows binaries for this release will probably be made with VS
2005 rather than VS 2003 even though that causes a small increase in
size as VS 2005 is likely to be in use by most downstream projects
now. scite/boundscheck/SciTE.vcproj has been updated to show no
warnings in VS 2005 even though it is still in VS 2003 format.
Changing the file to VS 2005 format would make it incompatible with VS
2003 but VS 2005 can use the file after running its upgrade wizard.

  Current code available from CVS and from
http://scintilla.sourceforge.net/scite.zip Source
http://scintilla.sourceforge.net/wscite.zip Windows executable

   Neil
Permalink | Reply | 0 comments |
headers
Philippe Lhoste | 3 Jan 2007 14:41
Picon

Re: Version 1.72 in about a week

Neil Hodgson a écrit :
>   I'm thinking of making a 1.72 release in around a week from now. If
> you have something you want included send it real soon.

I don't know if you plan to include my RE improvement (there is a small 
bugfix to send). I have started to work on the documentation update, I 
should finish it soon.

--

-- 
Philippe Lhoste
--  (near) Paris -- France
--  http://Phi.Lho.free.fr
--  --  --  --  --  --  --  --  --  --  --  --  --  --
Permalink | Reply | 0 comments |
headers
Steve Donovan | 3 Jan 2007 14:59
Picon

Enabling Lua loadlib for SciTE

There are some very nice loadable extensions for Lua 5,
like lposix. Unfortunately, out of the box SciTE doesn't
enable loadlib.

 Here is a patch:
1) comment out the #if PLATWIN and #endif lines
at src/ LuaExtension.cxx,1371 so that luaopen_loadlib
will be called
2) add the line #define USE_DLOPEN at the top of
lua/src/lib/loadlib.c to force dlopen to be used.
3) add the link flag -Wl,-export-dynamic
to the link command in the makefile.
(I added this directly to the line 106)

The last isn't strictly necessary to get loadlib going,
but you need it to expose the Lua API so that
Lua extensions can load; otherwise you can only
load plain libraries which can only supply a single
entry point to be called.  The SciTE binary
will be larger however (about 30%)

Here (for example) is how to get lposix loaded.
Go to http://www.tecgraf.puc-rio.br/~lhf/ftp/lua
and grab the lposix source; untar it and modify
Makefile so that the variable LUA points to
<scite-source>/lua. The build will  not
entirely succeed, but you will be left with a 
working lposix.so.

In a SciTE script, you can now say
(Continue reading)

Permalink | Reply | 5 comments |
headers
mitchell | 3 Jan 2007 16:51
Picon

Re: Enabling Lua loadlib for SciTE

Hi,

> There are some very nice loadable extensions for Lua 5,
> like lposix. Unfortunately, out of the box SciTE doesn't
> enable loadlib.
> 
>  Here is a patch:
> 1) comment out the #if PLATWIN and #endif lines
> at src/ LuaExtension.cxx,1371 so that luaopen_loadlib
> will be called
> 2) add the line #define USE_DLOPEN at the top of
> lua/src/lib/loadlib.c to force dlopen to be used.

Shouldn't the #define be wrapped in #if PLATGTK? IIRC, loadlib doesn't 
use DLOPEN in windows.

> 3) add the link flag -Wl,-export-dynamic
> to the link command in the makefile.
> (I added this directly to the line 106)
> 
> The last isn't strictly necessary to get loadlib going,
> but you need it to expose the Lua API so that
> Lua extensions can load; otherwise you can only
> load plain libraries which can only supply a single
> entry point to be called.  The SciTE binary
> will be larger however (about 30%)

What I ended up doing since I'm in linux and have lua installed on my 
machine (libs are in /usr/lib/ liblua50.{a,so}, liblualib50.{a,so}) is 
link the lua .so files to SciTE which resulted in a 100K size drop. Not
(Continue reading)

Permalink | Reply | 0 comments |
headers
Neil Hodgson | 3 Jan 2007 22:04
Picon

Re: Enabling Lua loadlib for SciTE

Steve Donovan:

> The last isn't strictly necessary to get loadlib going,
> but you need it to expose the Lua API so that
> Lua extensions can load; otherwise you can only
> load plain libraries which can only supply a single
> entry point to be called.  The SciTE binary
> will be larger however (about 30%)

   This exports a lot of symbols that aren't needed for Lua. Isn't
there an equivalent to a Windows DEF file that lists the functions to
be made available?

   Neil
Permalink | Reply | 3 comments |

Gmane