Hi,
I also tried with matju to link gem.dll, with no successfull results, apparently it depends on characters surounding function names we get with pexport,
maybe you will have better result with liblua.dll
http://www.stats.uwo.ca/faculty/murdoch/software/compilingDLLs/existingDLL.h...
----- "Hans-Christoph Steiner" hans@at.or.at a écrit :
Hmm, turns out it was already installed on the Windows build machine,
but I just updated it. Something with the way pdlua is being linked
makes it not able to find lua51.dll. My guess is because the Lua
build system doesn't generate a liblua51.dll.a to put in /usr/local/ lib, like the other libs there. libogg for example. I don't know howto generate the liblua51.dll.a, do you?
.hc
On Mar 26, 2011, at 9:03 PM, Martin Peach wrote:
If you get the latest source here: http://www.lua.org/ftp/lua-5.1.4.tar.gz and then: make mingw ...it should just work.
Martin
On 2011-03-26 20:20, Hans-Christoph Steiner wrote:
Yeah, we can build Lua on Windows and install it into the MinGW
path.
That's how the rest of the libraries are currently handled. Then
the
installer grabs the .dlls from the MinGW install path.
Have you successfully built Lua on Windows? If so, let me know the details, and I'll install it on the build server.
.hc
On Mar 26, 2011, at 6:31 PM, Martin Peach wrote:
From the gnu make manual it seems that running pkg-config is not recommended inside a Makefile. It should probably be done in the configure stage, but anyway, since liblua has different names on
each platform, pkg-config only returns that name. So I ended up just hard-coding liblua names and lua.h path for
each OS in the Makefile. Now the nightly build for Windows is failing because it can't
resolve -llua51.dll. It seems that there is no standard place to put thatdll. Sooo, maybe pd-extended should build lua as well, like portaudio,
or
should the dll be put in pd/bin, like pthreads.dll?
Martin
On 2011-03-18 23:55, Hans-Christoph Steiner wrote:
Martin,
I think you could put different pkg-config lines in the per-OS
section of the Makefile, and that would work for differences between Debian/Ubuntu, Mac OS X, and Windows liblua. That won't help if different GNU/Linux distros have different names for the libtho.
.hc
On Mar 18, 2011, at 5:02 PM, katja wrote:
Hello,
In the original Makefile.static for pdlua it is defined:
lua-5.1.3
This worked for me on OSX.
Katja
On Fri, Mar 18, 2011 at 7:07 PM, Claude Heiland-Allen <claude@goto10.org mailto:claude@goto10.org> wrote:
Hey,
On 18/03/11 17:38, Martin wrote:
The error actually seems to originate in pkg-config not finding lua5.1:
From my limited experience, Lua 5.1 libraries have different
names
all over the place, even in different GNU/Linux distros (lua51, lua5.1, lua5, lua, ...). A bit of a nightmare.
"pkg-config lua --libs" should do it on Mac OS X/Fink.
.hc
Claude
Pd-dev mailing list Pd-dev@iem.at mailto:Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@iem.at mailto:Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
"We have nothing to fear from love and commitment." - New York
Senator Diane Savino, trying to convince the NY Senate to pass a gay
marriage bill
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's
about as sensible to say we declare war on night attacks and
expect
we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom
I spent 33 years and four months in active military service and during
that period I spent most of my time as a high class muscle man for Big
Business, for Wall Street and the bankers. - General Smedley Butler
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Looks like it needs an 'import library'
.hc
On Mar 27, 2011, at 1:49 PM, patko wrote:
Hi,
I also tried with matju to link gem.dll, with no successfull
results, apparently it depends on characters surounding function
names we get with pexport,maybe you will have better result with liblua.dll
http://www.stats.uwo.ca/faculty/murdoch/software/compilingDLLs/existingDLL.h...
----- "Hans-Christoph Steiner" hans@at.or.at a écrit :
Hmm, turns out it was already installed on the Windows build machine,
but I just updated it. Something with the way pdlua is being linked
makes it not able to find lua51.dll. My guess is because the Lua build system doesn't generate a liblua51.dll.a to put in /usr/local/ lib, like the other libs there. libogg for example. I don't know
howto generate the liblua51.dll.a, do you?
.hc
On Mar 26, 2011, at 9:03 PM, Martin Peach wrote:
If you get the latest source here: http://www.lua.org/ftp/lua-5.1.4.tar.gz and then: make mingw ...it should just work.
Martin
On 2011-03-26 20:20, Hans-Christoph Steiner wrote:
Yeah, we can build Lua on Windows and install it into the MinGW
path.
That's how the rest of the libraries are currently handled. Then
the
installer grabs the .dlls from the MinGW install path.
Have you successfully built Lua on Windows? If so, let me know the details, and I'll install it on the build server.
.hc
On Mar 26, 2011, at 6:31 PM, Martin Peach wrote:
From the gnu make manual it seems that running pkg-config is not recommended inside a Makefile. It should probably be done in the configure stage, but anyway, since liblua has different names on
each platform, pkg-config only returns that name. So I ended up just hard-coding liblua names and lua.h path for each OS in the Makefile. Now the nightly build for Windows is failing because it can't resolve -llua51.dll. It seems that there is no standard place to put that
dll. Sooo, maybe pd-extended should build lua as well, like portaudio,
or
should the dll be put in pd/bin, like pthreads.dll?
Martin
On 2011-03-18 23:55, Hans-Christoph Steiner wrote:
Martin,
I think you could put different pkg-config lines in the per-OS section of the Makefile, and that would work for differences between Debian/Ubuntu, Mac OS X, and Windows liblua. That won't help if different GNU/Linux distros have different names for the lib
tho.
.hc
On Mar 18, 2011, at 5:02 PM, katja wrote:
> Hello, > > In the original Makefile.static for pdlua it is defined: > > lua-5.1.3 > > This worked for me on OSX. > > Katja > > > > On Fri, Mar 18, 2011 at 7:07 PM, Claude Heiland-Allen > <claude@goto10.org mailto:claude@goto10.org> wrote: > > Hey, > > > On 18/03/11 17:38, Martin wrote: > > The error actually seems to originate in pkg-config not > finding lua5.1: > > > From my limited experience, Lua 5.1 libraries have different
names
> all over the place, even in different GNU/Linux distros (lua51, > lua5.1, lua5, lua, ...). A bit of a nightmare. > > > "pkg-config lua --libs" should do it on Mac OS X/Fink. > > .hc > > > > Claude > > > _______________________________________________ > Pd-dev mailing list > Pd-dev@iem.at mailto:Pd-dev@iem.at > http://lists.puredata.info/listinfo/pd-dev > > > _______________________________________________ > Pd-dev mailing list > Pd-dev@iem.at mailto:Pd-dev@iem.at > http://lists.puredata.info/listinfo/pd-dev
"We have nothing to fear from love and commitment." - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's
about as sensible to say we declare war on night attacks and
expect
we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom
I spent 33 years and four months in active military service and
duringthat period I spent most of my time as a high class muscle man for
BigBusiness, for Wall Street and the bankers. - General Smedley Butler
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-- Patrice Colet
“We must become the change we want to see. - Mahatma Gandhi
Yes, and it's possible to build an import library from the dll with using dllwrap or dlltools, following the link I've posted
----- "Hans-Christoph Steiner" hans@at.or.at a écrit :
Looks like it needs an 'import library'
.hc
On Mar 27, 2011, at 1:49 PM, patko wrote:
Hi,
I also tried with matju to link gem.dll, with no successfull
results, apparently it depends on characters surounding function
names we get with pexport,maybe you will have better result with liblua.dll
http://www.stats.uwo.ca/faculty/murdoch/software/compilingDLLs/existingDLL.h...
----- "Hans-Christoph Steiner" hans@at.or.at a écrit :
Hmm, turns out it was already installed on the Windows build
machine,
but I just updated it. Something with the way pdlua is being
linked
makes it not able to find lua51.dll. My guess is because the Lua build system doesn't generate a liblua51.dll.a to put in
/usr/local/
lib, like the other libs there. libogg for example. I don't know
how
to generate the liblua51.dll.a, do you?
.hc
On Mar 26, 2011, at 9:03 PM, Martin Peach wrote:
If you get the latest source here: http://www.lua.org/ftp/lua-5.1.4.tar.gz and then: make mingw ...it should just work.
Martin
On 2011-03-26 20:20, Hans-Christoph Steiner wrote:
Yeah, we can build Lua on Windows and install it into the MinGW
path.
That's how the rest of the libraries are currently handled. Then
the
installer grabs the .dlls from the MinGW install path.
Have you successfully built Lua on Windows? If so, let me know
the
details, and I'll install it on the build server.
.hc
On Mar 26, 2011, at 6:31 PM, Martin Peach wrote:
From the gnu make manual it seems that running pkg-config is
not
recommended inside a Makefile. It should probably be done in
the
configure stage, but anyway, since liblua has different names
on
each platform, pkg-config only returns that name. So I ended up just hard-coding liblua names and lua.h path for each OS in the Makefile. Now the nightly build for Windows is failing because it can't resolve -llua51.dll. It seems that there is no standard place to put
that
dll. Sooo, maybe pd-extended should build lua as well, like
portaudio,
or
should the dll be put in pd/bin, like pthreads.dll?
Martin
On 2011-03-18 23:55, Hans-Christoph Steiner wrote: > > Martin, > > I think you could put different pkg-config lines in the per-OS > section > of the Makefile, and that would work for differences between > Debian/Ubuntu, Mac OS X, and Windows liblua. That won't help
if
> different GNU/Linux distros have different names for the lib
tho.
> > .hc > > On Mar 18, 2011, at 5:02 PM, katja wrote: > >> Hello, >> >> In the original Makefile.static for pdlua it is defined: >> >> lua-5.1.3 >> >> This worked for me on OSX. >> >> Katja >> >> >> >> On Fri, Mar 18, 2011 at 7:07 PM, Claude Heiland-Allen >> <claude@goto10.org mailto:claude@goto10.org> wrote: >> >> Hey, >> >> >> On 18/03/11 17:38, Martin wrote: >> >> The error actually seems to originate in pkg-config not >> finding lua5.1: >> >> >> From my limited experience, Lua 5.1 libraries have different
names
>> all over the place, even in different GNU/Linux distros
(lua51,
>> lua5.1, lua5, lua, ...). A bit of a nightmare. >> >> >> "pkg-config lua --libs" should do it on Mac OS X/Fink. >> >> .hc >> >> >> >> Claude >> >> >> _______________________________________________ >> Pd-dev mailing list >> Pd-dev@iem.at mailto:Pd-dev@iem.at >> http://lists.puredata.info/listinfo/pd-dev >> >> >> _______________________________________________ >> Pd-dev mailing list >> Pd-dev@iem.at mailto:Pd-dev@iem.at >> http://lists.puredata.info/listinfo/pd-dev > > > >
> > > "We have nothing to fear from love and commitment." - New York > Senator > Diane Savino, trying to convince the NY Senate to pass a gay > marriage > bill > > > > _______________________________________________ > Pd-dev mailing list > Pd-dev@iem.at > http://lists.puredata.info/listinfo/pd-dev
Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's
about as sensible to say we declare war on night attacks and
expect
we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom
I spent 33 years and four months in active military service and
duringthat period I spent most of my time as a high class muscle man for
Big
Business, for Wall Street and the bankers. - General Smedley Butler
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-- Patrice Colet
“We must become the change we want to see. - Mahatma Gandhi
On Sun, 27 Mar 2011, patko wrote:
I also tried with matju to link gem.dll, with no successfull results, apparently it depends on characters surounding function names we get with pexport,
I think that for the case of C, it's not so hard but it involves stdcall and/or cdecl options.
The C++ case is harder, as it involves putting characters in symbols that aren't allowed in C++, therefore we can't fake the symbols directly from C++, and we'd have to go through .def aliases, but afaict, pexport seems to be ignoring aliases ??? (hhhhheeeeelllllppppp.....!!!!!)
And then, there are C++ exceptions...
(why are GEM binaries still getting compiled with Visual C++ ? or why whatever else in the Pd world is compiled with Visual C++ ?)
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
-
Hans-Christoph Steiner -
Mathieu Bouchard -
patko