Bug 224644 - textproc/luaexpat: use proper INT definition, unbreak with lua53 right way
Summary: textproc/luaexpat: use proper INT definition, unbreak with lua53 right way
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: David Thiel
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-12-28 14:46 UTC by Dima Panov
Modified: 2018-07-30 07:24 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (lx)

Attachments
Unbreak with lua53 right way (577 bytes, patch)
2017-12-28 14:46 UTC, Dima Panov 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Dima Panov freebsd_committer freebsd_triage 2017-12-28 14:46:03 UTC 
Created attachment 189165 [details]
Unbreak with lua53 right way

Currently luaexpat fails to build against lua53 due to incorrect INT definition, LUA_INT_LONG doesn't affect at all int/long variations. 
But LUA_32BITS do it right way, and widely used in other lua-based ports
Comment 1 David Thiel freebsd_committer freebsd_triage 2018-01-11 20:33:35 UTC 
Does this still play nice with Lua 5.1?
Comment 2 Dima Panov freebsd_committer freebsd_triage 2018-01-12 01:19:28 UTC 
(In reply to David Thiel from comment #1)
Yes, this solution works with lua51 too. 
AFAIR, most distros build 3dparty lua components with LUA_32BITS
Comment 3 commit-hook freebsd_committer freebsd_triage 2018-01-12 21:49:10 UTC 
A commit references this bug:

Author: lx
Date: Fri Jan 12 21:48:52 UTC 2018
New revision: 458877
URL: https://svnweb.freebsd.org/changeset/ports/458877

Log:
  Correctly unbreak with lua53.

  PR:		224644
  Submitted by:	fluffy

Changes:
  head/textproc/luaexpat/Makefile
Comment 4 David Thiel freebsd_committer freebsd_triage 2018-01-12 23:06:38 UTC 
Committed, thanks!
Comment 5 Andrew "RhodiumToad" Gierth 2018-07-30 06:22:30 UTC 
Using LUA_32BITS is always the wrong fix. Always. It makes the module incompatible with the ABI of the Lua interpreter it's linked against, so that if it works it's only by chance.

The error here is happening due to the use of strict ANSI (-ansi) without specifying -std=c99. This breaks the logic in luaconf.h, which needs to get the same result as it did when building the Lua interpreter itself.

It's easy to demonstrate that the module fails its own test scripts when built with LUA_32BITS and passes if built with -std=c99 instead.
Comment 6 Andrew "RhodiumToad" Gierth 2018-07-30 07:24:50 UTC 
(In reply to andrew from comment #5)

I have opened a new bug for this:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230179