- Arch-general - lists.archlinux.org

Re: [arch-general] [arch-announce] New kernel packages and mkinitcpio hooks
by Amish 14 Nov '19

14 Nov '19

On 11/11/19 3:11 am, Arch Linux: Recent news updates: Giancarlo Razzolini wrote: > All our official kernels: linux, linux-lts, linux-zen and linux-hardened, do not install the actual kernel to /boot anymore. I would like to report an issue I faced due to this. Not an issue for everyone but can be an issue in a certain special cases. I have a custom package (in my custom repo) which modifies grub UI / menus (cosmetic change only) by putting some files in /etc/grub.d/ and regenerates /boot/grub/grub.cfg (by calling grub-mkconfig in package's post install script). This has been working fine from 2 years or so. Recently I released an update to that custom package but at the same time, upgrades to linux as well as linux-lts packages were also available in arch repository. And after upgrade, grub.cfg lost linux and linux-lts menu entries completely. What happened is: 1. mkinitcpio hook first removed vmlinuz-linux, vmlinuz-linux-lts and initrd files from /boot 2. My package got updated along with new versions of linux and linux-lts 3. My package's post install script ran grub-mkconfig but new vmlinuz files did not exist yet in /boot. So grub entries were not created for them. 4. mkinitcpio-install post transaction hook runs and copies kernel to /boot (but its too late for my post install scripts) So effectively this created an un-bootable system requiring manual booting. This is going to happen every time my package plus linux / linux-lts package get upgraded in the same pacman run. (i.e. this will not happen always but only in certain conditions) I know my issue is not common and I will also change my script to post transaction hook. But this is to warn anyone who has a custom package with post install script which looks for / expects kernel files in /boot. (like grub-mkconfig). Those scripts are going to break with the recent changes to kernel package and it would be advisable to put them in post transaction hook and that too after mkinitcpio-install scripts run. Regards, Amish

3 4

[arch-general] electron upgrade (7.1.1-1 -> 7.1.1-2) sort of broke functionality on several electron apps
by Javier 11 Nov '19

11 Nov '19

The 1st thing I noticed was that after the upgrade, the lectron apps no longer show up under the legacy tray, but instead on the more modern notification area (under LXQT). The 2nd thing, was the tray icons not doing any action. The 3rd thing, was that in order to use the electron apps, I had to call them with starting on tray, since the tray icons don't respond. And finally I can't try to iconify on tray, given the tray icons don't respond... Any one else experiencing the same? Other than just reverting to the prior electron, is there known workarounds for these issues? Has anyone faced them already, and dealt with them? Just in case a few electron apps experiencing the same: signal-desktop-bin whatsapp-nativefier slack-desktop Thanks ! -- Javier

1 1

Re: [arch-general] [arch-dev-public] New kernel packages and mkinitcpio hooks
by Damjan Georgievski 11 Nov '19

11 Nov '19

> This has been discussed a bit on the dracut thread, as well on some other threads over time. > I *personally* don't like the complexity of kernel-install that much. I've now read this twice on Arch mail lists, so I have to ask, without any presumptions on my side, what are the arguments against kernel-install? I must say, I don't see much complexity in it. It's only a 184 line bash script[1]. And as added feature, it decouples the kernel install from the kernel package install (and pacman), also defines couple of easy-to-use config locations like /etc/kernel/cmdline But I guess I might be missing something. [1] especially compared to dracut (not that they do the same thing), which seems much more complex, and that complexity did introduce bugs - for which I've sent a PR -- damjan

3 2

[arch-general] New kernel packages and mkinitcpio hooks? What does this mean to the average user?
by David C. Rankin 11 Nov '19

11 Nov '19

All, I have read the latest note from 11-10-19 at archlinux.org, e.g. New kernel packages and mkinitcpio hooks https://www.archlinux.org/news/new-kernel-packages-and-mkinitcpio-hooks/ However, I'm still left confused exactly "What this means to the average user?" When I read: <quote> All our official kernels: linux, linux-lts, linux-zen and linux-hardened, do not install the actual kernel to /boot anymore. The installation is done by mkinitcpio hooks and scripts, as well as removals. There is no need for any manual intervention. ... </quote> That tells me that I am not going to have to change the way I update kernels and that I won't have to do anything special to ensure all current hooks are run (mdadm_udev, etc...). The only changes I see in the mkinitcpio.pacnew file is that all double-quotes have been replaced by parenthesis, e.g. HOOKS="base udev autodetect modconf block mdadm_udev filesystems keyboard fsck" to HOOKS=(base udev autodetect modconf block mdadm_udev filesystems keyboard fsck) Which appears to effectively turn HOOKS into a bash array instead of a simple list/string. But beyond that I don't see anything that will have an impact on how kernels are installed or removed on update. Am I missing something there? -- David C. Rankin, J.D.,P.E.

3 3

Re: [arch-general] New kernel packages and mkinitcpio hooks
by Ondřej Hruška 11 Nov '19

11 Nov '19

Hi, I have a question regarding the kernel changes. It sounds like it might break my dm-crypt/luks setup with un-encrypted /boot partition, if the kernel is not in /boot anymore? Are there migration steps needed? I set it up exactly following the wiki. It is my understanding that it is the kernel who handles the password prompt and decryption. Or am I misunderstanding how it works? Ondrej Hruska

3 2

Re: [arch-general] [arch-announce] New kernel packages and mkinitcpio hooks
by Kusoneko 11 Nov '19

11 Nov '19

On November 10, 2019 9:41:24 PM UTC, "Arch Linux: Recent news updates: Giancarlo Razzolini" <arch-announce(a)archlinux.org> wrote: >All our official kernels: linux, linux-lts, linux-zen and >linux-hardened, do not install the actual kernel to /boot anymore. > >The installation is done by mkinitcpio hooks and scripts, as well as >removals. There is no need for any manual intervention. > >The intention is to make the kernel packages more self-contained, as >well as making the boot process more flexible, while also keeping it >backwards compatible. > >As of now, only mkinitcpio has hooks for handling kernels installations >and removals. We do not ship any for dracut yet, but it will have >similar hooks in the near feature. > >URL: >https://www.archlinux.org/news/new-kernel-packages-and-mkinitcpio-hooks/ >_______________________________________________ >arch-announce mailing list >arch-announce(a)archlinux.org >https://lists.archlinux.org/listinfo/arch-announce Hello, in the short time I've been subscribed to a bunch of these archlinux mailing lists, I've seen a few threads about mkinitcpio and dracut. What exactly are they for and what is the differences between the 2? Should one prefer to use dracut when equivalent support for it is implemented?

2 1

Re: [arch-general] [arch-dev-public] New kernel packages and mkinitcpio hooks
by Amish 11 Nov '19

11 Nov '19

On 11/11/19 3:11 am, Giancarlo Razzolini via arch-dev-public wrote: > Hi All, > > As most of you have noticed already, the kernel packages had some > recent changes > where they do not install the kernel to /boot, as well as they do not > have any kmod [0] > nor mkinitcpio hooks anymore. Neither they do install mkinitcpio > presets [1]. > > ... > > Also, kernel removals are handled by mkinitcpio as well. We want to > make the boot process more > flexible, while also keeping it backwards compatible by default. There > are a few changes I have > planned for the next mkinitcpio release [4] that will help even > further to achieve this. > > Thank you for the detailed explanation. However I have a question related to this change. Due to e1000e related bug in kernel 5.3, few of systems that I manage are still on kernel 5.2.5. # pacman -Q kmod mkinitcpio linux linux-lts kmod 26-2 mkinitcpio 25-2 linux 5.2.5.arch1-1 linux-lts 4.19.61-1 I am planning to do full system upgrade except linux package. i.e. pacman -Syu --ignore linux --ignore linux-lts Would the change in mkinitcpio and /boot create a broken system for me? You have written it is backward compatible. So do you mean it is backward compatible with older linux / linux-lts? In short, can I upgrade the system while still keeping older linux packages (till the e1000e bug is not resolved)? Thank you Amish.

2 1

[arch-general] Archlinux fail2ban not working
by Maykel Franco 09 Nov '19

09 Nov '19

Hi, I have this rule: jail.conf: [app-user] enabled = true port = 443 filter = user-app logpath = /var/log/user-app.log findtime = 1200 bantime = 480 maxretry = 3 ------------------------------- filter.d: user-app.conf [Definition] failregex = Unknown User .* $<HOST>:.*$ ignoreregex = ------------------------------- The content is logfile test /var/log/user-app.log: [12:48:35.315] Server1: Unknown User 'test' (109.103.148.2) [12:48:35.315] Server1: Unknown User 'test' (109.103.148.2) [12:48:35.315] Server1: Unknown User 'test' (109.103.148.2) [12:48:35.315] Server1: Unknown User 'test' (109.103.148.2) [12:48:35.315] Server1: Unknown User 'test' (109.103.148.2) [12:48:35.315] Server1: Unknown User 'test' (109.103.148.2) ------------------------------- And when test it, not working: fail2ban-regex /var/log/user-app.log /etc/fail2ban/filter.d/user-app.conf Running tests ============= Use failregex filter file : user-app, basedir: /etc/fail2ban Use log file : user-app.conf Use encoding : UTF-8 Results ======= Failregex: 0 total Ignoreregex: 0 total Date template hits: |- [# of hits] date format | [6] {^LN-BEG}24hour:Minute:Second `- Lines: 6 lines, 0 ignored, 0 matched, 6 missed [processed in 0.02 sec] |- Missed line(s): | [12:48:35.315] Server1: Unknown User 'test' (109.103.148.2) | [12:48:35.315] Server1: Unknown User 'test' (109.103.148.2) | [12:48:35.315] Server1: Unknown User 'test' (109.103.148.2) | [12:48:35.315] Server1: Unknown User 'test' (109.103.148.2) | [12:48:35.315] Server1: Unknown User 'test' (109.103.148.2) | [12:48:35.315] Server1: Unknown User 'test' (109.103.148.2) Whats wrong? Maybe the left timestamp? Thanks in advanced.

3 8

[arch-general] Failed to compile shadowsocksr-libev-git with yay.
by Hongyi Zhao 09 Nov '19

09 Nov '19

See the following: $ yay -S shadowsocksr-libev-git [...] acl.c: In function 'init_block_list': acl.c:74:90: error: '%s' directive writing up to 63 bytes into a region of size between 50 and 176 [-Werror=format-overflow=] 74 | "ip6tables -N %s; ip6tables -F %s; ip6tables -A OUTPUT -p tcp --tcp-flags RST RST -j %s"; | ^~ ...... 158 | sprintf(cli, ip6tables_init_chain, chain_name, chain_name, chain_name); | ~~~~~~~~~~ In file included from /usr/include/stdio.h:867, from ../libipset/include/ipset/ipset.h:14, from acl.c:23: /usr/include/bits/stdio2.h:36:10: note: '__builtin___sprintf_chk' output between 81 and 270 bytes into a destination of size 256 36 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 37 | __bos (__s), __fmt, __va_arg_pack ()); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ acl.c:67:87: error: '%s' directive writing up to 63 bytes into a region of size between 53 and 179 [-Werror=format-overflow=] 67 | "iptables -N %s; iptables -F %s; iptables -A OUTPUT -p tcp --tcp-flags RST RST -j %s"; | ^~ ...... 160 | sprintf(cli, iptables_init_chain, chain_name, chain_name, chain_name); | ~~~~~~~~~~ In file included from /usr/include/stdio.h:867, from ../libipset/include/ipset/ipset.h:14, from acl.c:23: /usr/include/bits/stdio2.h:36:10: note: '__builtin___sprintf_chk' output between 78 and 267 bytes into a destination of size 256 36 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 37 | __bos (__s), __fmt, __va_arg_pack ()); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ acl.c:92:5: error: '; firewall-cmd --direct...' directive writing 88 bytes into a region of size between 33 and 159 [-Werror=format-overflow=] 92 | "firewall-cmd --direct --add-chain ipv6 filter %s; \ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 93 | firewall-cmd --direct --passthrough ipv6 -F %s; \ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 94 | firewall-cmd --direct --passthrough ipv6 -A OUTPUT -p tcp --tcp-flags RST RST -j %s"; | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from /usr/include/stdio.h:867, from ../libipset/include/ipset/ipset.h:14, from acl.c:23: /usr/include/bits/stdio2.h:36:10: note: '__builtin___sprintf_chk' output between 186 and 375 bytes into a destination of size 256 36 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 37 | __bos (__s), __fmt, __va_arg_pack ()); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ acl.c:81:5: error: '; firewall-cmd --direct...' directive writing 88 bytes into a region of size between 33 and 159 [-Werror=format-overflow=] 81 | "firewall-cmd --direct --add-chain ipv4 filter %s; \ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 82 | firewall-cmd --direct --passthrough ipv4 -F %s; \ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 83 | firewall-cmd --direct --passthrough ipv4 -A OUTPUT -p tcp --tcp-flags RST RST -j %s"; | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from /usr/include/stdio.h:867, from ../libipset/include/ipset/ipset.h:14, from acl.c:23: /usr/include/bits/stdio2.h:36:10: note: '__builtin___sprintf_chk' output between 186 and 375 bytes into a destination of size 256 36 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 37 | __bos (__s), __fmt, __va_arg_pack ()); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ acl.c: In function 'free_block_list': acl.c:96:5: error: '%s' directive writing up to 63 bytes into a region of size between 61 and 124 [-Werror=format-overflow=] 96 | "firewall-cmd --direct --passthrough ipv6 -D OUTPUT -p tcp --tcp-flags RST RST -j %s; \ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 97 | firewall-cmd --direct --passthrough ipv6 -F %s; \ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 98 | firewall-cmd --direct --remove-chain ipv6 filter %s"; | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...... 184 | sprintf(cli, firewalld6_remove_chain, chain_name, chain_name, chain_name); | ~~~~~~~~~~ In file included from /usr/include/stdio.h:867, from ../libipset/include/ipset/ipset.h:14, from acl.c:23: /usr/include/bits/stdio2.h:36:10: note: '__builtin___sprintf_chk' output between 189 and 378 bytes into a destination of size 256 36 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 37 | __bos (__s), __fmt, __va_arg_pack ()); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ acl.c:85:5: error: '%s' directive writing up to 63 bytes into a region of size between 61 and 124 [-Werror=format-overflow=] 85 | "firewall-cmd --direct --passthrough ipv4 -D OUTPUT -p tcp --tcp-flags RST RST -j %s; \ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 86 | firewall-cmd --direct --passthrough ipv4 -F %s; \ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 87 | firewall-cmd --direct --remove-chain ipv4 filter %s"; | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...... 186 | sprintf(cli, firewalld_remove_chain, chain_name, chain_name, chain_name); | ~~~~~~~~~~ In file included from /usr/include/stdio.h:867, from ../libipset/include/ipset/ipset.h:14, from acl.c:23: /usr/include/bits/stdio2.h:36:10: note: '__builtin___sprintf_chk' output between 189 and 378 bytes into a destination of size 256 36 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 37 | __bos (__s), __fmt, __va_arg_pack ()); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ acl.c:76:90: error: '%s' directive writing up to 63 bytes into a region of size between 50 and 176 [-Werror=format-overflow=] 76 | "ip6tables -D OUTPUT -p tcp --tcp-flags RST RST -j %s; ip6tables -F %s; ip6tables -X %s"; | ^~ ...... 179 | sprintf(cli, ip6tables_remove_chain, chain_name, chain_name, chain_name); | ~~~~~~~~~~ In file included from /usr/include/stdio.h:867, from ../libipset/include/ipset/ipset.h:14, from acl.c:23: /usr/include/bits/stdio2.h:36:10: note: '__builtin___sprintf_chk' output between 81 and 270 bytes into a destination of size 256 36 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 37 | __bos (__s), __fmt, __va_arg_pack ()); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ acl.c:69:87: error: '%s' directive writing up to 63 bytes into a region of size between 53 and 179 [-Werror=format-overflow=] 69 | "iptables -D OUTPUT -p tcp --tcp-flags RST RST -j %s; iptables -F %s; iptables -X %s"; | ^~ ...... 181 | sprintf(cli, iptables_remove_chain, chain_name, chain_name, chain_name); | ~~~~~~~~~~ In file included from /usr/include/stdio.h:867, from ../libipset/include/ipset/ipset.h:14, from acl.c:23: /usr/include/bits/stdio2.h:36:10: note: '__builtin___sprintf_chk' output between 78 and 267 bytes into a destination of size 256 36 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 37 | __bos (__s), __fmt, __va_arg_pack ()); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors make[2]: *** [Makefile:778: libshadowsocks_libev_la-acl.lo] Error 1 make[2]: Leaving directory '/home/werner/.cache/yay/shadowsocksr-libev-git/src/shadowsocksr-libev/src' make[1]: *** [Makefile:478: all-recursive] Error 1 make[1]: Leaving directory '/home/werner/.cache/yay/shadowsocksr-libev-git/src/shadowsocksr-libev' make: *** [Makefile:387: all] Error 2 ==> ERROR: A failure occurred in build(). Aborting... Error making: shadowsocksr-libev-git -- Hongsheng Zhao <hongyi.zhao(a)gmail.com> Institute of Semiconductors, Chinese Academy of Sciences GnuPG DSA: 0xD108493

4 3

[arch-general] Failed to compile dnsmasq latest git version with `-DHAVE_LUASCRIPT' on Manjaro.
by Hongyi Zhao 09 Nov '19

09 Nov '19

Hi, See the following: $ uname -a Linux Manjaro 5.3.7-2-MANJARO #1 SMP PREEMPT Tue Oct 22 18:56:05 UTC 2019 x86_64 GNU/Linux $ yay -S lua52 $ make COPTS="-DHAVE_DBUS -DHAVE_IDN -DHAVE_LUASCRIPT -DHAVE_CONNTRACK -DHAVE_DNSSEC" -j24 Package lua5.2 was not found in the pkg-config search path. Perhaps you should add the directory containing `lua5.2.pc' to the PKG_CONFIG_PATH environment variable Package 'lua5.2', required by 'virtual:world', not found Package lua5.2 was not found in the pkg-config search path. Perhaps you should add the directory containing `lua5.2.pc' to the PKG_CONFIG_PATH environment variable Package 'lua5.2', required by 'virtual:world', not found make[1]: Entering directory '/home/data/software/anti-gfw/dns/dnsmasq/dnsmasq.git/src' cc -o dnsmasq cache.o rfc1035.o util.o option.o forward.o network.o dnsmasq.o dhcp.o lease.o rfc2131.o netlink.o dbus.o bpf.o helper.o tftp.o log.o conntrack.o dhcp6.o rfc3315.o dhcp-common.o outpacket.o radv.o slaac.o auth.o ipset.o domain.o dnssec.o blockdata.o tables.o loop.o inotify.o poll.o rrfilter.o edns0.o arp.o crypto.o dump.o ubus.o metrics.o -ldbus-1 -lidn -lnetfilter_conntrack -lnfnetlink -lnettle -lhogweed -lgmp /usr/bin/ld: helper.o: in function `grab_extradata_lua.part.0': helper.c:(.text+0x3e): undefined reference to `lua_pushstring' /usr/bin/ld: helper.c:(.text+0x52): undefined reference to `lua_setfield' /usr/bin/ld: helper.o: in function `create_helper': helper.c:(.text+0x308): undefined reference to `luaL_newstate' /usr/bin/ld: helper.c:(.text+0x317): undefined reference to `luaL_openlibs' /usr/bin/ld: helper.c:(.text+0x333): undefined reference to `luaL_loadfilex' /usr/bin/ld: helper.c:(.text+0x352): undefined reference to `lua_pcallk' /usr/bin/ld: helper.c:(.text+0x36d): undefined reference to `lua_tolstring' /usr/bin/ld: helper.c:(.text+0x3b1): undefined reference to `lua_settop' /usr/bin/ld: helper.c:(.text+0x3c4): undefined reference to `lua_getglobal' /usr/bin/ld: helper.c:(.text+0x3d5): undefined reference to `lua_type' /usr/bin/ld: helper.c:(.text+0x3ef): undefined reference to `lua_settop' /usr/bin/ld: helper.c:(.text+0x6e3): undefined reference to `lua_getglobal' /usr/bin/ld: helper.c:(.text+0x6f4): undefined reference to `lua_type' /usr/bin/ld: helper.c:(.text+0x70e): undefined reference to `lua_settop' /usr/bin/ld: helper.c:(.text+0xbb0): undefined reference to `lua_getglobal' /usr/bin/ld: helper.c:(.text+0xbc1): undefined reference to `lua_pushstring' /usr/bin/ld: helper.c:(.text+0xbd1): undefined reference to `lua_createtable' /usr/bin/ld: helper.c:(.text+0xc0a): undefined reference to `lua_pushnumber' /usr/bin/ld: helper.c:(.text+0xc22): undefined reference to `lua_setfield' /usr/bin/ld: helper.c:(.text+0xc3b): undefined reference to `lua_pushstring' /usr/bin/ld: helper.c:(.text+0xc53): undefined reference to `lua_setfield' /usr/bin/ld: helper.c:(.text+0xc6c): undefined reference to `lua_pushstring' /usr/bin/ld: helper.c:(.text+0xc84): undefined reference to `lua_setfield' /usr/bin/ld: helper.c:(.text+0xe7c): undefined reference to `lua_pushstring' /usr/bin/ld: helper.c:(.text+0xe94): undefined reference to `lua_setfield' /usr/bin/ld: helper.c:(.text+0xebd): undefined reference to `lua_pushstring' /usr/bin/ld: helper.c:(.text+0xed5): undefined reference to `lua_setfield' /usr/bin/ld: helper.c:(.text+0xeef): undefined reference to `lua_pushstring' /usr/bin/ld: helper.c:(.text+0xf07): undefined reference to `lua_setfield' /usr/bin/ld: helper.c:(.text+0xf1f): undefined reference to `lua_callk' /usr/bin/ld: helper.c:(.text+0xf92): undefined reference to `lua_getglobal' /usr/bin/ld: helper.c:(.text+0xfa3): undefined reference to `lua_type' /usr/bin/ld: helper.c:(.text+0xfbd): undefined reference to `lua_pushstring' /usr/bin/ld: helper.c:(.text+0xfcd): undefined reference to `lua_createtable' /usr/bin/ld: helper.c:(.text+0xfe7): undefined reference to `lua_pushstring' /usr/bin/ld: helper.c:(.text+0xfff): undefined reference to `lua_setfield' /usr/bin/ld: helper.c:(.text+0x1010): undefined reference to `lua_pushstring' /usr/bin/ld: helper.c:(.text+0x1028): undefined reference to `lua_setfield' /usr/bin/ld: helper.c:(.text+0x104a): undefined reference to `lua_pushstring' /usr/bin/ld: helper.c:(.text+0x127d): undefined reference to `lua_getglobal' /usr/bin/ld: helper.c:(.text+0x128e): undefined reference to `lua_type' /usr/bin/ld: helper.c:(.text+0x12ac): undefined reference to `lua_callk' /usr/bin/ld: helper.c:(.text+0x13d0): undefined reference to `lua_pushstring' /usr/bin/ld: helper.c:(.text+0x13e0): undefined reference to `lua_createtable' /usr/bin/ld: helper.c:(.text+0x13fa): undefined reference to `lua_pushstring' /usr/bin/ld: helper.c:(.text+0x1412): undefined reference to `lua_setfield' /usr/bin/ld: helper.c:(.text+0x142c): undefined reference to `lua_pushstring' /usr/bin/ld: helper.c:(.text+0x15bd): undefined reference to `lua_pushstring' /usr/bin/ld: helper.c:(.text+0x15d5): undefined reference to `lua_setfield' /usr/bin/ld: helper.c:(.text+0x15fb): undefined reference to `lua_pushstring' /usr/bin/ld: helper.c:(.text+0x1613): undefined reference to `lua_setfield' /usr/bin/ld: helper.c:(.text+0x162d): undefined reference to `lua_pushstring' /usr/bin/ld: helper.c:(.text+0x1645): undefined reference to `lua_setfield' /usr/bin/ld: helper.c:(.text+0x165f): undefined reference to `lua_pushstring' /usr/bin/ld: helper.c:(.text+0x1677): undefined reference to `lua_setfield' /usr/bin/ld: helper.c:(.text+0x16ea): undefined reference to `lua_getglobal' /usr/bin/ld: helper.c:(.text+0x16fb): undefined reference to `lua_type' /usr/bin/ld: helper.c:(.text+0x1750): undefined reference to `lua_pushnumber' /usr/bin/ld: helper.c:(.text+0x1768): undefined reference to `lua_setfield' /usr/bin/ld: helper.c:(.text+0x178d): undefined reference to `lua_callk' /usr/bin/ld: helper.c:(.text+0x1844): undefined reference to `lua_pushstring' /usr/bin/ld: helper.c:(.text+0x185c): undefined reference to `lua_setfield' /usr/bin/ld: helper.c:(.text+0x188f): undefined reference to `lua_pushstring' /usr/bin/ld: helper.c:(.text+0x18a7): undefined reference to `lua_setfield' collect2: error: ld returned 1 exit status make[1]: *** [/home/data/software/dnsmasq.git/Makefile:164: dnsmasq] Error 1 make[1]: Leaving directory '/home/data/software/dnsmasq.git/src' make: *** [Makefile:86: all] Error 2 How to solve this issue? -- Hongsheng Zhao <hongyi.zhao(a)gmail.com> Institute of Semiconductors, Chinese Academy of Sciences GnuPG DSA: 0xD108493

4 4