# pkg-config --libs luajit-2.0 -lluajit-jit-5.1 but the libs are named as follows: /usr/lib64/libluajit-2.0.a /usr/lib64/libluajit-2.0.so /usr/lib64/libluajit-2.0.so.0 One of it is wrong, I don't really know how you intended to do this in the first place, but this mismatch will break every build system that uses "pkg-config --libs luajit-2.0". This is true for: dev-lang/luajit-2.0.0_beta8_p1 dev-lang/luajit-2.0.0_beta10 dev-lang/luajit-2.0.0
maybe this was intended to be used with a virtual package and some kind of eselect?
I just ran into the same issue.
Temporary, use ebuilds from lua overlay. I'll try to propose them in gentoo after 2.0.2 release
(In reply to Vadim A. Misbakh-Soloviov (mva) from comment #3) > Temporary, use ebuilds from lua overlay. > I'll try to propose them in gentoo after 2.0.2 release Pointing users to overlays is suboptimal. If you can provide a patch, please attach it here.
(In reply to Julian Ospald (hasufell) from comment #4) > Pointing users to overlays is suboptimal. If you can provide a patch, please > attach it here. Not that I have a patch. Just LJ-2.0.1 (and upcoming 2.0.2, and also 2.1.9999), installed by my ebuilds from lua-overlay, works fine. So, I only can attach ebuild 2.0.1 for now (and ask mabi to don't forget to bump it to 2.0.2 in few days).
Created attachment 349328 [details] luajit-2.0.1.ebuild Actually, it PDEPENDs on dev-lua/iluajit (to have normally-working interactive console, since by default it is almost unusable) and virtual/lua[luajit] (since I hardly working on luajit-compatibility of many Lua-related packages). So, I suggest you [or mabi] to at least take dev-lua/iluajit to the tree.
(In reply to Julian Ospald (hasufell) from comment #1) > maybe this was intended to be used with a virtual package and some kind of > eselect? we aren't going to add an eselect module for lua any time soon.
(In reply to Vadim A. Misbakh-Soloviov (mva) from comment #5) > (In reply to Julian Ospald (hasufell) from comment #4) > > Pointing users to overlays is suboptimal. If you can provide a patch, please > > attach it here. > > Not that I have a patch. Just LJ-2.0.1 (and upcoming 2.0.2, and also > 2.1.9999), installed by my ebuilds from lua-overlay, works fine. So, I only > can attach ebuild 2.0.1 for now (and ask mabi to don't forget to bump it to > 2.0.2 in few days). don't know why you're trying to push mabi into this issue. he has nothing to do with luajit. not that I don't want him helping, but he isn't luajit maintainer at this time.
(In reply to Vadim A. Misbakh-Soloviov (mva) from comment #6) > Created attachment 349328 [details] > luajit-2.0.1.ebuild > > Actually, it PDEPENDs on dev-lua/iluajit (to have normally-working > interactive console, since by default it is almost unusable) and > virtual/lua[luajit] (since I hardly working on luajit-compatibility of many > Lua-related packages). > > So, I suggest you [or mabi] to at least take dev-lua/iluajit to the tree. your 'interactive' use flag in luajit is totally wrong. you shouldn't use USE flags just to force a dep, and this is even worse with a pdep. the iluajit project is interesting, but it DOES NOT belongs to dev-lang/luajit :(
(In reply to Rafael G. Martins from comment #8) > don't know why you're trying to push mabi into this issue. he has nothing to > do with luajit. not that I don't want him helping, but he isn't luajit > maintainer at this time. I just (okay, by mistake) mentioned mabi as a person, I thought as lua-herd and a person I discussed on luajit few moments earlier. Okay, I see, that he's not luajit maintainer already, so, hasufell, s/mabi/rafaelmartins/ ;). (In reply to Rafael G. Martins from comment #9) > your 'interactive' use flag in luajit is totally wrong. you shouldn't use > USE flags just to force a dep, and this is even worse with a pdep. > the iluajit project is interesting, but it DOES NOT belongs to > dev-lang/luajit :( It is just for user convenience. It is useflags behaviour in my mind: to let user enable or disable features, that he migh want (interactive shell in luajit) or not (systemd support in some packages). Including providing PDEPENDs (at least, in my mind). Of course, I could be wrong. Any way, I was inspired by "emacs" useflag, that doing all the same. Only difference is that I added "+" to "interactive" (since I suggest it to user, since it was a part of making luajit possible to fully replace C lua), while 'emacs' has no "+". Am I wrong? Should I delete both emacs and interactive flags?
(In reply to Vadim A. Misbakh-Soloviov (mva) from comment #10) > Am I wrong? Should I delete both emacs and interactive flags? But okay, ragarding to devmanual, I'm wrong, so, okay, I'll fix it all. But anyway: $ grep PDEP /usr/portage/dev-lang/lua/lua-5.2.1.ebuild PDEPEND="emacs? ( app-emacs/lua-mode )"
Created attachment 349374 [details] luajit-2.0.1.ebuild This is ebuild, fixed in manner, rafaelmartins mention (to not use USE-flags to PDEPEND something). While it is still pdepends on virtual/lua[luajit].
Uhm. Sorry, I found one bug, I added when improving that ebuild, and I also forgot to make some more improvements. I'll add once more fixed ebuild in some time.
Created attachment 349394 [details] luajit-2.0.1.ebuild Finally fixed (I hope). Still suggest to discuss adding virtual/lua (with: RDEPEND=" !luajit? ( dev-lang/lua ) luajit? ( dev-lang/luajit:2 ) " to the tree. Also, ebuild contains reference to hotfix1 patch from upstream's download page.
(In reply to Vadim A. Misbakh-Soloviov (mva) from comment #12) > Created attachment 349374 [details] > luajit-2.0.1.ebuild > > This is ebuild, fixed in manner, rafaelmartins mention (to not use USE-flags > to PDEPEND something). > While it is still pdepends on virtual/lua[luajit]. I'm not going to accept any ebuild that differs that much of the ebuild that is in tree. Please stop trying to introduce new things on luajit ebuilds.
(In reply to Rafael G. Martins from comment #15) > (In reply to Vadim A. Misbakh-Soloviov (mva) from comment #12) > > Created attachment 349374 [details] > > luajit-2.0.1.ebuild > > > > This is ebuild, fixed in manner, rafaelmartins mention (to not use USE-flags > > to PDEPEND something). > > While it is still pdepends on virtual/lua[luajit]. > > I'm not going to accept any ebuild that differs that much of the ebuild that > is in tree. Please stop trying to introduce new things on luajit ebuilds. and btw, as hasufell just remembered me on IRC, our >2.0.0_beta7 ebuilds are hardmasked, because they include experimental patches, that were rejected by upstream, and we may remove them any time soon. please base your ebuilds on 2.0.0_beta7, if you want to get it committed in tree unmasked. thanks.
fixed in luajit-2.0.1_p1
