[PATCH] OS X / macOS and Test Suite

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

[PATCH] OS X / macOS and Test Suite

Paige DePol
There are only very few issues with OS X (now macOS from 10.12+) and the
test suite, some of which I detailed in a previous post a few years ago.
I thought I would do an update on the issues for those using OS X/macOS.


In the 'attrib.lua' file on line 240 there is a comment that says the
variable 'p' should be redefined to "_" under OS X. If this is done then the
dynamic library loader will not find the requested functions, at least under
10.11.6+, older versions may still require the leading underscore.

Also, on line 246, if the "lib1.so" library is not present the error check
for non-existant libraries must be changed from "absent" to "open".

Related to the library issue in 'attrib.lua' is the makefile in the 'libs'
directory. It needs to have "-undefined dynamic_lookup" appended to the end
of the CFLAGS line, otherwise the linker will generate a bunch of unknown
symbol errors and won't create the test libraries. This is required for
those versions of OS X that are using the 'clang' compiler.

In 'main.lua' at line 233 there is a check that requires the readline
library to echo the prompt when stdout is redirected. Under OS X this echo
does not occur so the test will always fail. I simply commented out this
test as it is not critical that it passes.

In 'files.lua' there is a test that tries an invalid seek on STDIN, however,
under OS X this seek does not fail so I have simply commented out the test.

Also in 'files.lua' at line 643 there is a test for killing a process under
a subshell, in OS X the kill test is changed to "signal, 1" from "exit".


The entire full test suite works for me under OS X 10.11.6 with the six
small tweaks I have detailed above. I have attached a patch file to this
post to make the detailed changes for anyone running OS X (now macOS).

Note the specific issue with the dynamic libraries may require the leading
underscore for older versions of OS X, and the change to the Makefile for
the testing libraries expects the 'clang' compiler to be used.

Hopefully this info can be of assistance to anyone else using OS X/macOS
who would like to run the full and complete test suite.

~Paige


tests.patch (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] OS X / macOS and Test Suite

dyngeccetor8
Hi Paige!

I think it will be more convenient also provide link to code repository with
patches.

Then you will not have to worry about posting any further patch versions, you
may just announce patch in this list, like any other software. And also, when
someone years later will find your messages, he will also get link to repository
with most recent version.

-- Martin

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] OS X / macOS and Test Suite

Paige DePol
dyngeccetor8 <[hidden email]> wrote:

> Hi Paige!
>
> I think it will be more convenient also provide link to code repository with
> patches.
>
> Then you will not have to worry about posting any further patch versions, you
> may just announce patch in this list, like any other software. And also, when
> someone years later will find your messages, he will also get link to repository
> with most recent version.
>
> -- Martin

I am in the process of creating a site actually. Just thought I would share a
very quick patch for anyone who uses OS X/macOS is all!

Also, the lua-l mailing list archive[1] does save attachments for posterity,
especially as other online resources themselves may not be online permanently.

~Paige

[1] http://lua-users.org/lists/lua-l/


Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] OS X / macOS and Test Suite

Luiz Henrique de Figueiredo
In reply to this post by Paige DePol
> small tweaks I have detailed above. I have attached a patch file to this
> post to make the detailed changes for anyone running OS X (now macOS).

I'm running OS X 10.11.6 and the only change I need is replacing "-shared"
with "-bundle -undefined dynamic_lookup" in lua-5.3.4-tests/libs/makefile.
The compiler is Apple LLVM version 8.0.0 (clang-800.0.42.1).

The attached Makefile works fine. Put it in an empty folder and run the
commands below:

make get lua
make basic complete
make debug

# Makefile for running Lua tests

PLAT= macosx
V= lua-5.3.4
R=
W= ftp

N= $V$R
LUA_DIR= ../$V/src
LUA= $(LUA_DIR)/lua
T= $V-tests

GET= wget
GET= curl -R -O

basic:
        cd $T; $(LUA) -e'_U=true' all.lua

complete:
        cd $T; $(MAKE) -C libs LUA_DIR=../$(LUA_DIR)
        cd $T; $(LUA) -e'_U=true' all.lua

internal: debug basic complete

debug:
        cd $T; cp -f ltests/* $(LUA_DIR)
        cd $T; $(MAKE) -C $(LUA_DIR) MYCFLAGS='-DLUA_USER_H='"'"'"ltests.h"'"'" LUA_O="lua.o ltests.o" clean $(PLAT)

get:
        $(GET) http://www.lua.org/$W/$N.tar.gz
        $(GET) http://www.lua.org/tests/$N-tests.tar.gz
        tar zxf $N.tar.gz
        tar zxf $N-tests.tar.gz

lua:
        cd $V; make $(PLAT)

clean:
        cd $V; make clean

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] OS X / macOS and Test Suite

Paige DePol
Luiz Henrique de Figueiredo <[hidden email]> wrote:

>> small tweaks I have detailed above. I have attached a patch file to this
>> post to make the detailed changes for anyone running OS X (now macOS).
>
> I'm running OS X 10.11.6 and the only change I need is replacing "-shared"
> with "-bundle -undefined dynamic_lookup" in lua-5.3.4-tests/libs/makefile.
> The compiler is Apple LLVM version 8.0.0 (clang-800.0.42.1).

I accidentally left the modification of the SRC directory in my patch,
I have an updated one I will put on my site that removes that oversight.

I modify the SRC path to append '/src' as I leave the ltests files in the
'test/ltests' directory, which is at the same level as 'src' and 'doc' from
the default Lua distribution, so I needed that addition to compile the
sources via Makefile... which I almost never do, I typically use Xcode.

From what I can determine it looks like under OS X/macOS '-bundle' is the
correct flag, but it seems '-shared' is a synonym under clang to maintain
compatibility. There is also .dylib (dynamic library) which are created
via the '-dynamiclib' flag and have some other requirements.

Are you saying the rest of the Lua Test Suite executes on your system
without the small tweaks to the 3 lua I mentioned? As those tweaks seem to
be platform specific, and we're on the same system, you should also have to
make those adjustment for the complete test suite to succeed.

Okay, so I created your provided Makefile and ran into a few issues.

The first issue was that I got an invalid instruction error the first time
the newly compiled 'lua' tried to run. Under Xcode an additional compiler
flag is added, '-mmacosx-version-min=10.11', which is set when you specify
the target OS X version for your build. I don't know how many people using
OS X build Lua from the Makefile, but this may be an issue for others as
well. A default might be to specify a low version, which will potentially
let Lua compile and work out of the box for greater numbers of people, with
a notice somewhere to adjust the version to the min version they support.

Once I added the '-mmacosx-version-min' flag I also had the edit the ltests
Makefile to add the '-undefined dynamic_lookup' as I just got a bunch of
unknown symbol errors when it tried to compile the test libraries, but that
was an expected error as your test Makefile didn't address that issue.

The last issue is the tests seem to complete in less than 1 second for both
the basic and complete build targets, which obviously means the tests were
not running in their entirety.

You are specifying "_U=true" for both the basic and complete tests, once I
removed that flag for the complete build target the test suite attempts to
run with all tests enabled... and asserts on main.lua at line 239.

I applied my first fix, and the tests complete until file.lua asserts, at
which point I apply the two fixes for file.lua and retry the tests.

The tests fully complete at this point, however, if I remove the shared test
library 'lib1.so' (and prevent it being rebuilt) the tests will assert out
again in attrib.lua.

Apply that final fix and the test suite will once again run to completion.

Please try disabling the '_U=true' flag for the complete tests on your end
and verify that the test suite also needs the tweaks I provided to fully run
on your system as well? Thanks!

~Paige


Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] OS X / macOS and Test Suite

Luiz Henrique de Figueiredo
> Please try disabling the '_U=true' flag for the complete tests on your end
> and verify that the test suite also needs the tweaks I provided to fully run
> on your system as well? Thanks!

Yes, disabling '_U=true' requires the changes you've provided.
Sorry for the noise. Thanks.

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] OS X / macOS and Test Suite

Paige DePol
Luiz Henrique de Figueiredo <[hidden email]> wrote:

>> Please try disabling the '_U=true' flag for the complete tests on your end
>> and verify that the test suite also needs the tweaks I provided to fully run
>> on your system as well? Thanks!
>
> Yes, disabling '_U=true' requires the changes you've provided.
> Sorry for the noise. Thanks.

No problem, hopefully the patch can help our fellow OS X/macOS users run the
complete Lua Test Suite as well. It has been an indispensable test for me in
my Lua hacking efforts, so thank you for creating such a verbose test suite!

One question, when you compile Lua from the command line under your OS X do
you not have to specify the "-mmacosx-version-min" flag? If I do not specify
the flag I get the "unknown instruction" error when the test suite attempts
to run. The interpreter itself will run, so obviously there is some sort of
optimisation that fails pretty quickly as the test suite doesn't even manage
to get any output before dying.

I was just wondering if it may be a good idea for the OS X/macOS build
target to include a default value for "-mmacosx-version-min"? Perhaps just
10.5 or something, with a note to change the value for the specific version
of OS X/macOS the compiler will be targeting.

~Paige


Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] OS X / macOS and Test Suite

Luiz Henrique de Figueiredo
> One question, when you compile Lua from the command line under your OS X do
> you not have to specify the "-mmacosx-version-min" flag?

No, I don't have to specify this flag. The macosx Makefile target in the
official tarballs does not use this flag and it works fine.

Perhaps you're using some switch in XCode that makes this necessary.

I used to have to set the MACOSX_DEPLOYMENT_TARGET environment variable
in the old days of OS X 10.4 but this is not needed for 10.5+.

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] OS X / macOS and Test Suite

Paige DePol
Luiz Henrique de Figueiredo <[hidden email]> wrote:

>> One question, when you compile Lua from the command line under your OS X do
>> you not have to specify the "-mmacosx-version-min" flag?
>
> No, I don't have to specify this flag. The macosx Makefile target in the
> official tarballs does not use this flag and it works fine.
>
> Perhaps you're using some switch in XCode that makes this necessary.
>
> I used to have to set the MACOSX_DEPLOYMENT_TARGET environment variable
> in the old days of OS X 10.4 but this is not needed for 10.5+.

Specifying MACOSX_DEPLOYMENT_TARGET is just another way of setting that
flag, however, the command line variant takes precedent. Do you perhaps
still have MACOSX_DEPLOYMENT_TARGET set as an environment variable?


pmd$ echo $MACOSX_DEPLOYMENT_TARGET

pmd$


I get nothing, which may be why I need to specify the min version during
compile time and you do not? If you do not have the environment variable
set then I guess it's a mystery as to what is happening! ;)

I get the Invalid Instruction error when I try to build Lua from the command
line, not within Xcode as it automatically adds the minimum version flag.

I am using Xcode 8.2.1 (8C1002) with the Command Line Tools installed:


pmd$ clang --version
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin15.6.0
Thread model: posix


It seems odd that we would get different behaviour, but if you search online
for the "-mmacosx-version-min" flag you will see a good number of people who
have similar issues compiling code across a number of open source projects.

I just thought it would be prudent to put a note somewhere in the README for
people building under OS X/macOS to save them some potenital frustration.

~Paige


Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] OS X / macOS and Test Suite

Luiz Henrique de Figueiredo
> Do you perhaps
> still have MACOSX_DEPLOYMENT_TARGET set as an environment variable?

No. It's been *ages* since I've used MACOSX_DEPLOYMENT_TARGET.
 
> I am using Xcode 8.2.1 (8C1002) with the Command Line Tools installed:

Same here.

So, a mystery... But Like I said, we've been building Lua on the command line
on Mac OS X for ages with no problems reported.

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] OS X / macOS and Test Suite

Paige DePol
Luiz Henrique de Figueiredo <[hidden email]> wrote:

>> Do you perhaps
>> still have MACOSX_DEPLOYMENT_TARGET set as an environment variable?
>
> No. It's been *ages* since I've used MACOSX_DEPLOYMENT_TARGET.
>
>> I am using Xcode 8.2.1 (8C1002) with the Command Line Tools installed:
>
> Same here.
>
> So, a mystery... But Like I said, we've been building Lua on the command line
> on Mac OS X for ages with no problems reported.

Actually, this is the first time I've encountered a problem building Lua
from a Makefile as well... I recently, well I guess nine months ago now,
upgraded to El Capitan. Looking around online, however, it seems I am not
alone with OS X/macOS deciding to build things strangely. That said, a
simple search for "osx invalid instruction" gives an immediate solution!

From what I have been reading online if you do not specify a target it is
supposed to use the currently selected SDK, which should default to your
version of OS X/macOS... which it obviously fails to do correctly for me.

Interestingly, however, if I take the compiled binary that gives me an
invalid instruction on my 10.11 system and copy it to my server, which is
running 10.8.5 (wow! do I need to upgrade that) it runs the entire test
suite just fine! On my partner's system, which is running 10.9, the tests
also all succeed... no invalid instructions on either system.

Even odder, when I add the -mmacosx-version-min=10.11 flag to the build and
the resulting executable works on my 10.11 system... it still actually works
on both the 10.8 and 10.9 systems without any issues... not what I expected!

Thanks for your feedback on this Luiz, it is appreciated, I wonder what is
going on with my system and building without that flag? :(

~Paige


Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] OS X / macOS and Test Suite

Jay Carlson
In reply to this post by Luiz Henrique de Figueiredo
Disclaimer: I'm not an OS X expert. Corrections gladly accepted.

On 2017-12-05 Tue, at 05:46, Luiz Henrique de Figueiredo <[hidden email]> wrote:

>> Do you perhaps
>> still have MACOSX_DEPLOYMENT_TARGET set as an environment variable?
>
> No. It's been *ages* since I've used MACOSX_DEPLOYMENT_TARGET.

As Paige says, the default is the current OS; you shouldn't see problems on the machine you're on, and maybe not for the previous release or two.

ANSI C programs have the fewest problems. When you start building or linking frameworks beyond this, it matters more, I think.

If you're using C++ anywhere below 10.9, you'll definitely need to set the deployment target consistently, or add more flags. As of 10.9, the C++ standard library switched to libc++. I had some vendor binary libraries that use libc++, so I need to do this to work in builds for OS X 10.7 and 10.8:

MACOSX_DEPLOYMENT_TARGET = 10.7
LFLAGS += -stdlib=libc++
CXXFLAGS += -stdlib=libc++

In this case the problem was clear at build-time, in particular at link-time. It was also morally questionable, since the upstream binary libraries should be built this way too.

 If you only support 10.9 forward, this particular bug won't bite you. But I don't know how many more problems there are without this; the 10.11->10.12 transition seemed to have a bunch of homebrew bugs filed.

Jay