Hi,
Yes, in summary there is no bug after all, yes you can close it.
Recommendations for windows users:
Problem 1: "The module is not GPL compatible".
My suggestion is to provide a more generic Makefile able to link external libraries such Sqlite. Attached you can find the final version of the Makefile I used to build the module.
Another recommendation is to test if DLL symbols are exported using tools such pexports or Dependecy walker.
Problem 2: "The emacs module can't be found".
This is easy to handle by adding the path to sqlite3.dll to windows environment variables. Other solution is put the sqlite3.dll in the same folder where the emacs.exe is located.
In case that someone add the path to sqlite3.dll in emacs init file, it should be located before calling the emacs module. In my case, I move my windows path setup in emacs
to the top of the init file.
I think the most important was the support I receive from you, thank you.
Levis
On Wednesday, October 5, 2016 4:48 AM, "npostavs@users.sourceforge.net" <npostavs@users.sourceforge.net> wrote:
Mambo Levis <
mambo.levis@gmail.com> writes:
> Please, notice that this time the plugin_is_GPL_compatible. The
> problem is now that the module can't be found when a sqlite3.dll
> symbol is used.
What was the difference between this time and the previous time?
>
> The only thing left to do was to put sqlite.dll in the emacs\bin
> folder and Voilà, now it works. In fact I had already added the path
> and used to sqlite3.dll in my emacs init file, but the location was
> wrong; after my emacs-modules collection.
So there is no bug after all? Should we just close this report, or is
there perhaps some guidance we should add to the documentation about how
to build modules on Windows?
Makefile