From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Problems trying to update lua-5.4.3 Date: Mon, 19 Apr 2021 11:06:31 +0100 Message-ID: In-Reply-To: <58f6d42e-122a-70ec-e624-a24a3abdc326@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8697750188099369775==" List-Id: --===============8697750188099369775== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, Some packages do not follow the standard naming process (which normally is in= dicated by autotools). That is normally not a good idea, but what can you do? They simply use the version number of the package (which normally isn=E2=80= =99t the same as the library version) in the filename (liblua-5.3.so). liblua= .so is a symlink to that file and that is it. There is no change to have a pa= tch level library next to it. So we would just ship liblua-5.x.so and we will always have to ship all softw= are that is linked against it. -Michael > On 16 Apr 2021, at 20:56, Adolf Belka wrote: >=20 > Hi Michael, >=20 > On 14/04/2021 20:02, Michael Tremer wrote: >> Hello, >>> On 14 Apr 2021, at 13:33, Adolf Belka wrote: >>>=20 >>> Hallo, >>>=20 >>> On 14/04/2021 11:08, Michael Tremer wrote: >>>> Hello, >>>> I think you can use this as inspiration: >>>> http://www.linuxfromscratch.org/blfs/view/svn/general/lua.html >>>> The patch should already be updated and should be working. >>> The patch there is the shared_library-1.patch >>>=20 >>> I can certainly use it in my build but the patch I was having the questio= ns about is the autotoolize.patch This is not mentioned in the Beyond Linux = >>From Scratch link. Also not in the BLFS link for the previous version of lua-= 5.3.4 >>>=20 >>> Searching I have found that this patch is designed to have the lua build = use the standard autotools programs. However the locations in Fedora and othe= r repositories I found seem to stop at lua-5.3.0 >> Apart from Fedora, it is worth checking Gentoo because they are usually ve= ry up to date and should have patches. Archlinux is a good option, too, becau= se they keep their patches to a minimum and are a rolling release as well. > I checked Gentoo but they also seemed to have stopped at 5.3.1 > Arch Linux have followed the BLFS process and have not autotoolized lua. >>> Any help with where to find a newer version of the autotoolize.patch that= is meant for lua-5.4.3 >> If there is none available, we can just use the steps without configure li= ke BLFS. > So in the end I followed the BLFS process and it built successfully. >=20 > One thing I noticed is that the old rootfile had the plain .so library unco= mmented and the .so.5.3 library commented out. This is the opposite of what i= s normally done. Is this correct for lua? Should I follow the same process fo= r 5.4.3 or should I change it? >=20 > Regards, >=20 > Adolf. >> -Michael >>>=20 >>> Regards, >>>=20 >>> Adolf >>>> -Michael >>>>> On 13 Apr 2021, at 22:06, Adolf Belka wrote: >>>>>=20 >>>>> Hi All, >>>>>=20 >>>>>=20 >>>>> I have been working on updating lua from 5.3.5 to 5.4.3 >>>>>=20 >>>>> I updated the autotoolize.patch and the shared_library-1.patch and foun= d that 5.4.3 no longer has lbitlib.c in the tarball src directory >>>>>=20 >>>>>=20 >>>>> I removed lbitlib.c from the liblua_la_SOURCES section in the diff for = lua-5.3.5/src/Makefile.am >>>>>=20 >>>>> ----------------------------------------------------------- >>>>> +AM_CFLAGS =3D -Wall >>>>> + >>>>> +include_HEADERS =3D lua.h lualib.h lauxlib.h lua.hpp >>>>> + >>>>> +nodist_include_HEADERS =3D luaconf.h >>>>> + >>>>> +lib_LTLIBRARIES =3D liblua.la >>>>> +liblua_la_LDFLAGS =3D -release @MAJOR_VERSION@ >>>>> +liblua_la_SOURCES =3D \ >>>>> + lapi.c lauxlib.c lbaselib.c lbitlib.c lcode.c lcorolib.c lctype.c = ldblib.c \ >>>>> + ldebug.c ldo.c ldump.c lfunc.c lgc.c linit.c liolib.c llex.c lmath= lib.c lmem.c \ >>>>> + loadlib.c lobject.c lopcodes.c loslib.c lparser.c lstate.c lstring= .c lstrlib.c \ >>>>> + ltable.c ltablib.c ltm.c lundump.c lutf8lib.c lvm.c lzio.c \ >>>>> + lapi.h lcode.h lctype.h ldebug.h ldo.h lfunc.h lgc.h llex.h llimit= s.h \ >>>>> + lmem.h lobject.h lopcodes.h lparser.h lstate.h lstring.h ltable.h = ltm.h \ >>>>> + lundump.h lvm.h lzio.h >>>>> + >>>>>=20 >>>>> ----------------------------------------------------------- >>>>>=20 >>>>> and then lua built without any problems. >>>>>=20 >>>>>=20 >>>>> So lua built successfully but looking at the files in the tarball src d= irectory for 5.3.5 & 5.4.3 there are some differences >>>>>=20 >>>>> The following files >>>>> lua.c >>>>> luac.c >>>>> lua.h >>>>> luaconf.h >>>>> lualib.h >>>>> lauxlib.h >>>>> lprefix.h >>>>>=20 >>>>> are in both 5.3.5 & 5.4.3 but not in the liblua_la_SOURCES section. Thi= s may be deliberate, I can't tell. >>>>>=20 >>>>> However lbitlib.c is in 5.3.5 & liblua_la_SOURCES but not in 5.4.3 Is = that a problem for IPFire's use of lua? >>>>>=20 >>>>>=20 >>>>> ljumptab.h and lopnames.h are not in 5.3.5 or liblua_la_SOURCES but are= in 5.4.3 Should these now be included somewhere in the Makefile.am or elsew= here or is it OK to ignore them for IPFire? >>>>>=20 >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Adolf. --===============8697750188099369775==--