Summary: | >=net-dns/bind-9.8.2[dlz] - -o driver.so .libs/driver.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Drunkard Zhang <gongfan193> |
Component: | Current packages | Assignee: | Christian Ruppert (idl0r) <idl0r> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | adamcarter3, Adrian.Bassett, anton.kochkov, bug, daniel, david+gentoo.org, eras, gibgibon, gseanmcg, HidekiAI, hwoarang, jcwren, kparent, liva, m.pontus, m.ustymenko, matrix47, matthew.finkel, mgmadden, phantom4, qdii, reuben-gentoo-bugzilla, slyfox, stevan, tampakrap, yamadharma |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Indicative build log
bind-9.9.0.patch build.log from now also failing net-dns/bind-9.8.1_p1 |
Description
Drunkard Zhang
2012-03-01 09:15:28 UTC
+1 - seeing the exact same problem here also. Please attach the entire build log to this bug report. If the error is happening in dlzexternal then the solution is the patch from here -> http://lists.fedoraproject.org/pipermail/scm-commits/2011-November/683368.html Created attachment 303901 [details] Indicative build log I too am haiving the same problem. The patch mentioned in comment #3 would likely be applicable but I am not sure how to use a one-off like that in portage. Likely others would want the same fix put into the tree (if indeed it is the fix). Created attachment 303969 [details, diff]
bind-9.9.0.patch
To put patches in localpatch order for net-dns/bind use this: (also used by glibc, php ...) mkdir -p /etc/portage/patches/net-dns/bind-9.9.0 cp bind-9.9.0.patch /etc/portage/patches/net-dns/bind-9.9.0/ vi /usr/portage/net-dns/bind/bind-9.9.0.ebuild add post_src_prepare() { epatch_user } before src_configure() { ebuild /usr/portage/net-dns/bind/bind-9.9.0.ebuild digest emerge =net-dns/bind-9.9.0 I can confirm this patch works. Thanks! Created attachment 304119 [details]
build.log from now also failing net-dns/bind-9.8.1_p1
I am seeing the same problem. Not only on my unstable ~amd64 system, but also on my stable amd64 system with bind-9.8.1_p1.
bind-9.8.1_p1 was successfully build on Feb 22, but now the rebuild because of the added USE flag static-libs is failing, as shown in the attached build.log.
USE=static-libs does not fix it for me in 9.9.0, but rebuilding bind-9.8.1_p1 after removing the line "$(use_enable static-libs static) \" does work.
(I did not try USE=static-libs with 9.8.1_p1 or removing that line from 9.9.0)
So it looks like just specifying this configure option is breaking the buildsystem of the tests of the DLZ patch.
*** Bug 406753 has been marked as a duplicate of this bug. *** Same problems with bind 9.8.1-p1 and 9.9.0 Patch works for me. *** Bug 406507 has been marked as a duplicate of this bug. *** Interesting. This thing does not work: $ /tmp/portage/net-dns/bind-9.9.0/work/bind-9.9.0/bin/tests/system/dlzexternal:libtool --mode=link --tag=CC x86_64-pc-linux-gnu-gcc -shared -o driver.so driver.lo libtool: link: x86_64-pc-linux-gnu-gcc -o driver.so .libs/driver.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: ld returned 1 exit status While this works: $ /tmp/portage/net-dns/bind-9.9.0/work/bind-9.9.0/bin/tests/system/dlzexternal: [sf] /tmp/portage/net-dns/bind-9.9.0/work/bind-9.9.0/bin/tests/system/dlzexternal:libtool --mode=link --tag=CC "x86_64-pc-linux-gnu-gcc -shared" -o driver.so driver.lo libtool: link: x86_64-pc-linux-gnu-gcc -shared -o driver.so .libs/driver.o Makefile.in does not look sane: > driver.@SO@: ${SO_OBJS} > ${LIBTOOL_MODE_LINK} @SO_LD@ -o $@ driver.@O@ Could be worked around by: > driver.@SO@: ${SO_OBJS} > ${LIBTOOL_MODE_LINK} "@SO_LD@" -o $@ driver.@O@ But dropping that test sounds better. Might be a problem with our libtool implementation. CCed base-system to hear the denial :] @base-system: any progress on this issue? *** Bug 411361 has been marked as a duplicate of this bug. *** *** Bug 416633 has been marked as a duplicate of this bug. *** pretty sure this isn't a bug in libtool. you should be outputting to xxx.la, not xxx.so, if you want to create shared libs with libtool. since the output didn't end in an .la, libtool thinks you're creating a program, not a shared library, and so links it accordingly (which is why you get an error related to missing main). most likely you want to do something like: driver.la: ${LIBTOOL_MODE_LINK} @SO_LD@ -o $@ driver.@O@ -module -avoid-version \ -rpath $(LIBDIR) driver.@SO@: driver.la ln -s .libs/$@ $@ *** Bug 416841 has been marked as a duplicate of this bug. *** This bug also affects net-dns/bind-9.9.1. The same fix with the same patch works. Shouldn't disabling dlz with -dlz remove any dependency requirements on mysql and berkdb? I have a very small household DNS running on bind, and don't need dlz. But to get it to compile, I have to spec -dlz -mysql -berkdb. This bug is not dependent upon USE=dlz, by the way. It also occurs without it, and the same patch fixes it either way. The failure is still present in bind-9.9.1_p1: libtool: link: x86_64-pc-linux-gnu-gcc -o driver.so .libs/driver.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: ld returned 1 exit status make[4]: *** [driver.so] Error 1 make[4]: Leaving directory `/var/tmp/portage/net-dns/bind-9.9.1_p1/work/bind-9.9.1-P1/bin/tests/system/dlzexternal' make[3]: *** [subdirs] Error 1 make[3]: Leaving directory `/var/tmp/portage/net-dns/bind-9.9.1_p1/work/bind-9.9.1-P1/bin/tests/system' make[2]: *** [subdirs] Error 1 make[2]: Leaving directory `/var/tmp/portage/net-dns/bind-9.9.1_p1/work/bind-9.9.1-P1/bin/tests' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/var/tmp/portage/net-dns/bind-9.9.1_p1/work/bind-9.9.1-P1/bin' make: *** [subdirs] Error 1 * ERROR: net-dns/bind-9.9.1_p1 failed (compile phase): * emake failed And the patch still fixes the problem. Part of the problem here seems to be that the build is still descending into dlzexternal even if you told it not to use DLZ. The other part of the problem is that it appears the dlzexternal code has a link problem. tests are now disabled, for now.. So this error shouldn't occur again. This also seems to happening in 9.8.3-p1 just emerged 9.9.1_p1 version from main tree - it now builds ok with and without dlz. |