lua-users home
lua-l archive

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

It was thus said that the Great Stefano once stated:
> On 7 September 2015 at 03:39, Sean Conner <sean@conman.org> wrote:
> >   Thanks for the work, but I'm having difficulty understanding the output
> > from all this.  For instance, I only found one of my modules [1] in the
> > Windows output [2] and while I would like to fix the issue, I don't [3]
> > use Windows, so I'm at a loss as to how to fix this issue:
> >
> > env.c
> > env.c(44): warning C4273: '__p__environ': inconsistent dll linkage
> > C:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt\stdlib.h(1158): note: see previous definition of '__p__environ'
> > Microsoft (R) Incremental Linker Version 14.00.23026.0
> > Copyright (C) Microsoft Corporation.  All rights reserved.
> >
> >    Creating library org/conman/env.lib and object org/conman/env.exp
> > Installing https://luarocks.org/org.conman.env-1.0.1-0.rockspec...
> > Using https://luarocks.org/org.conman.env-1.0.1-0.rockspec... switching to 'build' mode
> > cl /nologo /MD /O2 -c -Foenv.obj -IC:/ste/luarocks/2.2/include env.c
> > link -dll -def:env.def -out:org/conman/env.dll C:/ste/luarocks/2.2/lua51.lib env.obj
> > Updating manifest for C:/ste/luarockstree/lib/luarocks/rocks
> > org.conman.env 1.0.1-0 is now built and installed in C:/ste/luarockstree (license: LGPL)
> 
> That is just a warning, it builds fine (see below).
> If you are concerned please send me privately a test and I can run on
> my Windows VM.

  I'm going to try to clarify my thoughts on this.  I work exclusively under
Unix [1].  If there's an issue with Unix, I know enough to fix the issue,
even under less used Unix system [2].  If a Windows user can use the code,
that's great, but if any issues come up, I can't fix them.

  The closest I've come to programming under Windows is OS/2, and that was
OS/2 1.x back in 1990.  I've used Windows and I can puzzle my way around a
Windows system as a user, but not as a programmer.  And honestly, I can't
remember the last time I actually *used* a Windows system for any length of
time (I know I used one regularly for several months back in 1997 but past
that ... ).

  That doesn't mean I can't offer some theories as to the issues (like the
one above).  Just from "inconsistent dll linkage" and "previous definition
of '__p_environ' I can gather that there was no issue with compilation but
with linking the final output to make it run, and that there stands a better
than even chance of some runtime issue happening.  I can even make some
reasonable predictions as to the outcome:  it won't run; it'll crash; it'll
print out gibberish; it may even work on your system but not another one.

  But I don't know enough about the Windows environment [7] to even come up
with a valid test.  Sure, I can provide some code:

	env = require "org.conman.env"
	for name,val in pairs(env) do
		print(name,val)
	end

but that's not a full test.  That will get you to the "it'll print out
gibberish; it may even work on your system" test.  Writing a test requires
knowledge of the expected output, and for Windows, I don't know what to even
expect for a typical environment.  For Windows, I have to depend on a
Windows programmer to fix the problem and push a patch my way (and hack, I
would welcome that!).  And if the fix isn't too onerous I'll accept it [8]. 
But I have to trust the source that this does indeed, fix the problem.

  You might be thinking that I'm harping on the Windows angle too much, and
yes, I'll cop to that, but it's indicative of a larger issue---I'm sure
there are programmers out there writing Lua modules under Windows and
wouldn't have the first clue about fixing the issues under Linux or Mac OS-X
(or Solaris or FreeBSD or ... ) and will have the same issues as I am with
respect to Windows [9].

  Going back to your original email:

> More precisely, could you please:
> 
> 1. Check wether your Lua rock pass or fail at [3]. If it pass, champagne!
> Otherwise...
> 
> 2. Check wether it fails due to a platform-independent error (like
> contending the module name) at [4]. If so, please fix and celebrate
> accordingly. Otherwise...
> 
> 3. Check wether it fails due to platform-dependent errors at [5]. If so,
> please fix and celebrate accordingly. If not...
> 
> 4. It means your rock depends on something that is not available as can be
> seen at [6]. Please blame or blackmail whoever is responsible, or fix your
> broken dependency.

  This comes across as all errors are all very easy and everybody should be
able to do this with a minimum of fuss.  Unfortuntely, that is not the case. 
I appreciate your effort (I really do) but please be aware that it might
not be all that easy for module authors to address all issues across all
platforms and some additional effort might be required.

  -spc

[1]	Linux, Mac OS-X (home and at work) and Solaris (work only).  

[2]	FreeBSD, OpenBSD, NetBSD, HP-UX, AIX, Irix, heck, even probably
	Xenix and <shudder>SCO</shudder>.

[3]	Not my footnote.

[4]	Not my footnote.

[5]	Not my footnote.

[6]	Not my footnote.

[7]	Pun intended

[8]	Too onerous---to the point where I have to work around *the patch*
	and I probably won't accept it.  I don't care enough about Windows
	to take onerous patches.

[9]	Too onerous---to the point where they have to work around *the
	patch* and they probably won't accept it.  They dont' care enough
	about Unix to take onerous patches.