Re: svn commit: r250379 - in head/usr.sbin/bsnmpd/modules: . snmp_hast
On Thu, May 09, 2013 at 01:05:35PM +0300, Mikolaj Golub wrote: On Thu, May 09, 2013 at 11:22:43AM +0300, Konstantin Belousov wrote: Why do you need libl.a ? If only for yywrap(), then re-implementing it for the module seems to be trivial. Yes, it is like so. Thanks! I am now considering two possible solutions: 1) As it is suggested above, add trivial yywrap() and link without -ll. 2) Add '%option noyywrap' to hastd/token.l, and link hastd, hastctl and snmp_hast without -ll (it looks like yywrap is needed only when parsing more than one file). See the patches below. It looks both solutions work for me and I personally prefer the second one. Me too. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com pgpMSHj2QWPrW.pgp Description: PGP signature
Re: svn commit: r250379 - in head/usr.sbin/bsnmpd/modules: . snmp_hast
On Wed, May 08, 2013 at 04:44:54PM -0700, Peter Wemm wrote: On Wed, May 8, 2013 at 4:25 PM, Peter Wemm pe...@wemm.org wrote: On Wed, May 8, 2013 at 1:03 PM, Mikolaj Golub troc...@freebsd.org wrote: Author: trociny Date: Wed May 8 20:03:37 2013 New Revision: 250379 URL: http://svnweb.freebsd.org/changeset/base/250379 Log: HAST module for bsnmpd(1). Reviewed by: harti, pjd MFC after:2 weeks This breaks world on just about everything other than i386, and it is technically broken there too but doesn't actually cause a build failure. You cannot link a .so file against a non-pic library, libl.a in this case. === usr.sbin/bsnmpd/modules/snmp_hast (all)^M /usr/obj/usr/src/tmp/usr/bin/ld: /usr/obj/usr/src/tmp/usr/lib/libl.a(libyywrap.o ): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC^M /usr/obj/usr/src/tmp/usr/lib/libl.a: could not read symbols: Bad value^M *** [snmp_hast.so.6] Error code 1^M Hmm. It seems clang optimizes something away that gcc doesn't. When building with clang the problem doesn't show up. Sorry for breaking build. I am always running tinderbox before commits like this, which did not help this time. Now I will run it twice, with both clang and gcc. Thank you for r250394. I will investigate how to fix this. Any suggestions are highly appreciated. -- Mikolaj Golub ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r250379 - in head/usr.sbin/bsnmpd/modules: . snmp_hast
On Thu, May 09, 2013 at 10:14:14AM +0300, Mikolaj Golub wrote: On Wed, May 08, 2013 at 04:44:54PM -0700, Peter Wemm wrote: On Wed, May 8, 2013 at 4:25 PM, Peter Wemm pe...@wemm.org wrote: On Wed, May 8, 2013 at 1:03 PM, Mikolaj Golub troc...@freebsd.org wrote: Author: trociny Date: Wed May 8 20:03:37 2013 New Revision: 250379 URL: http://svnweb.freebsd.org/changeset/base/250379 Log: HAST module for bsnmpd(1). Reviewed by: harti, pjd MFC after:2 weeks This breaks world on just about everything other than i386, and it is technically broken there too but doesn't actually cause a build failure. You cannot link a .so file against a non-pic library, libl.a in this case. === usr.sbin/bsnmpd/modules/snmp_hast (all)^M /usr/obj/usr/src/tmp/usr/bin/ld: /usr/obj/usr/src/tmp/usr/lib/libl.a(libyywrap.o ): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC^M /usr/obj/usr/src/tmp/usr/lib/libl.a: could not read symbols: Bad value^M *** [snmp_hast.so.6] Error code 1^M Hmm. It seems clang optimizes something away that gcc doesn't. When building with clang the problem doesn't show up. Sorry for breaking build. I am always running tinderbox before commits like this, which did not help this time. Now I will run it twice, with both clang and gcc. Thank you for r250394. I will investigate how to fix this. Any suggestions are highly appreciated. Why do you need libl.a ? If only for yywrap(), then re-implementing it for the module seems to be trivial. pgpYmEK9L0IsR.pgp Description: PGP signature
Re: svn commit: r250379 - in head/usr.sbin/bsnmpd/modules: . snmp_hast
On Thu, May 09, 2013 at 11:22:43AM +0300, Konstantin Belousov wrote:
On Thu, May 09, 2013 at 10:14:14AM +0300, Mikolaj Golub wrote:
On Wed, May 08, 2013 at 04:44:54PM -0700, Peter Wemm wrote:
On Wed, May 8, 2013 at 4:25 PM, Peter Wemm pe...@wemm.org wrote:
On Wed, May 8, 2013 at 1:03 PM, Mikolaj Golub troc...@freebsd.org
wrote:
Author: trociny
Date: Wed May 8 20:03:37 2013
New Revision: 250379
URL: http://svnweb.freebsd.org/changeset/base/250379
Log:
HAST module for bsnmpd(1).
Reviewed by: harti, pjd
MFC after:2 weeks
This breaks world on just about everything other than i386, and it is
technically broken there too but doesn't actually cause a build
failure.
You cannot link a .so file against a non-pic library, libl.a in this
case.
=== usr.sbin/bsnmpd/modules/snmp_hast (all)^M
/usr/obj/usr/src/tmp/usr/bin/ld:
/usr/obj/usr/src/tmp/usr/lib/libl.a(libyywrap.o
): relocation R_X86_64_32 against `a local symbol' can not be used when
making a
shared object; recompile with -fPIC^M
/usr/obj/usr/src/tmp/usr/lib/libl.a: could not read symbols: Bad value^M
*** [snmp_hast.so.6] Error code 1^M
Hmm. It seems clang optimizes something away that gcc doesn't. When
building with clang the problem doesn't show up.
Sorry for breaking build. I am always running tinderbox before commits
like this, which did not help this time. Now I will run it twice, with
both clang and gcc.
Thank you for r250394. I will investigate how to fix this. Any
suggestions are highly appreciated.
Why do you need libl.a ? If only for yywrap(), then re-implementing
it for the module seems to be trivial.
Yes, it is like so. Thanks! I am now considering two possible
solutions:
1) As it is suggested above, add trivial yywrap() and link without -ll.
2) Add '%option noyywrap' to hastd/token.l, and link hastd, hastctl
and snmp_hast without -ll (it looks like yywrap is needed only when
parsing more than one file).
See the patches below. It looks both solutions work for me and I
personally prefer the second one.
--
Mikolaj Golub
Index: usr.sbin/bsnmpd/modules/snmp_hast/yywrap.c
===
--- usr.sbin/bsnmpd/modules/snmp_hast/yywrap.c (revision 0)
+++ usr.sbin/bsnmpd/modules/snmp_hast/yywrap.c (working copy)
@@ -0,0 +1,8 @@
+int yywrap(void);
+
+int
+yywrap(void)
+{
+
+ return (1);
+}
Index: usr.sbin/bsnmpd/modules/snmp_hast/Makefile
===
--- usr.sbin/bsnmpd/modules/snmp_hast/Makefile (revision 250379)
+++ usr.sbin/bsnmpd/modules/snmp_hast/Makefile (working copy)
@@ -12,7 +12,7 @@ SRCS+= nv.c
SRCS+= parse.y pjdlog.c
SRCS+= proto.c proto_common.c proto_uds.c
SRCS+= token.l
-SRCS+= y.tab.h
+SRCS+= y.tab.h yywrap.c
MAN= snmp_hast.8
NO_WFORMAT=
@@ -30,7 +30,7 @@ CFLAGS+=-DYY_NO_INPUT
CFLAGS+= -DSNMPTREE_TYPES
DPADD= ${LIBL} ${LIBUTIL}
-LDADD= -ll -lutil
+LDADD= -lutil
XSYM= begemotHast
DEFS= ${MOD}_tree.def
Index: sbin/hastd/Makefile
===
--- sbin/hastd/Makefile (revision 250377)
+++ sbin/hastd/Makefile (working copy)
@@ -31,7 +31,7 @@ CFLAGS+=-DINET6
.endif
DPADD= ${LIBGEOM} ${LIBBSDXML} ${LIBSBUF} ${LIBL} ${LIBPTHREAD} ${LIBUTIL}
-LDADD= -lgeom -lbsdxml -lsbuf -ll -lpthread -lutil
+LDADD= -lgeom -lbsdxml -lsbuf -lpthread -lutil
.if ${MK_OPENSSL} != no
DPADD+= ${LIBCRYPTO}
LDADD+= -lcrypto
Index: sbin/hastd/token.l
===
--- sbin/hastd/token.l (revision 250377)
+++ sbin/hastd/token.l (working copy)
@@ -46,6 +46,7 @@ int lineno;
%option noinput
%option nounput
+%option noyywrap
%%
control { DP; return CONTROL; }
Index: sbin/hastctl/Makefile
===
--- sbin/hastctl/Makefile (revision 250377)
+++ sbin/hastctl/Makefile (working copy)
@@ -32,8 +32,8 @@ CFLAGS+=-DINET6
CFLAGS+=-DYY_NO_UNPUT
CFLAGS+=-DYY_NO_INPUT
-DPADD= ${LIBL} ${LIBUTIL}
-LDADD= -ll -lutil
+DPADD= ${LIBUTIL}
+LDADD= -lutil
.if ${MK_OPENSSL} != no
DPADD+= ${LIBCRYPTO}
LDADD+= -lcrypto
Index: usr.sbin/bsnmpd/modules/snmp_hast/Makefile
===
--- usr.sbin/bsnmpd/modules/snmp_hast/Makefile (revision 250379)
+++ usr.sbin/bsnmpd/modules/snmp_hast/Makefile (working copy)
@@ -29,8 +29,8 @@ CFLAGS+=-DYY_NO_UNPUT
CFLAGS+=-DYY_NO_INPUT
CFLAGS+= -DSNMPTREE_TYPES
-DPADD= ${LIBL} ${LIBUTIL}
-LDADD= -ll -lutil
+DPADD= ${LIBUTIL}
+LDADD= -lutil
XSYM= begemotHast
DEFS= ${MOD}_tree.def
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r250379 - in head/usr.sbin/bsnmpd/modules: . snmp_hast
On Thu, May 09, 2013 at 01:05:35PM +0300, Mikolaj Golub wrote: Yes, it is like so. Thanks! I am now considering two possible solutions: 1) As it is suggested above, add trivial yywrap() and link without -ll. 2) Add '%option noyywrap' to hastd/token.l, and link hastd, hastctl and snmp_hast without -ll (it looks like yywrap is needed only when parsing more than one file). See the patches below. It looks both solutions work for me and I personally prefer the second one. I do not have any opinion, use what you prefer. pgpjQJeor8TrU.pgp Description: PGP signature
svn commit: r250379 - in head/usr.sbin/bsnmpd/modules: . snmp_hast
Author: trociny
Date: Wed May 8 20:03:37 2013
New Revision: 250379
URL: http://svnweb.freebsd.org/changeset/base/250379
Log:
HAST module for bsnmpd(1).
Reviewed by: harti, pjd
MFC after:2 weeks
Added:
head/usr.sbin/bsnmpd/modules/snmp_hast/
head/usr.sbin/bsnmpd/modules/snmp_hast/BEGEMOT-HAST-MIB.txt (contents,
props changed)
head/usr.sbin/bsnmpd/modules/snmp_hast/Makefile (contents, props changed)
head/usr.sbin/bsnmpd/modules/snmp_hast/hast_snmp.c (contents, props changed)
head/usr.sbin/bsnmpd/modules/snmp_hast/hast_tree.def (contents, props
changed)
head/usr.sbin/bsnmpd/modules/snmp_hast/snmp_hast.8 (contents, props changed)
Modified:
head/usr.sbin/bsnmpd/modules/Makefile
Modified: head/usr.sbin/bsnmpd/modules/Makefile
==
--- head/usr.sbin/bsnmpd/modules/Makefile Wed May 8 19:11:47 2013
(r250378)
+++ head/usr.sbin/bsnmpd/modules/Makefile Wed May 8 20:03:37 2013
(r250379)
@@ -10,6 +10,7 @@ _snmp_atm= snmp_atm
SUBDIR=${_snmp_atm} \
snmp_bridge \
+ snmp_hast \
snmp_hostres \
snmp_mibII \
snmp_pf \
Added: head/usr.sbin/bsnmpd/modules/snmp_hast/BEGEMOT-HAST-MIB.txt
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/usr.sbin/bsnmpd/modules/snmp_hast/BEGEMOT-HAST-MIB.txt Wed May 8
20:03:37 2013(r250379)
@@ -0,0 +1,298 @@
+--
+-- Copyright (c) 2013 Mikolaj Golub troc...@freebsd.org
+-- All rights reserved.
+--
+-- Redistribution and use in source and binary forms, with or without
+-- modification, are permitted provided that the following conditions
+-- are met:
+-- 1. Redistributions of source code must retain the above copyright
+--notice, this list of conditions and the following disclaimer.
+-- 2. Redistributions in binary form must reproduce the above copyright
+--notice, this list of conditions and the following disclaimer in the
+--documentation and/or other materials provided with the distribution.
+--
+-- THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+-- ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+-- IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+-- ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+-- FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+-- DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+-- OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+-- HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+-- LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+-- OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+-- SUCH DAMAGE.
+--
+-- $FreeBSD$
+--
+
+BEGEMOT-HAST-MIB DEFINITIONS ::= BEGIN
+
+IMPORTS
+MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
+Counter64, Integer32
+ FROM SNMPv2-SMI
+TEXTUAL-CONVENTION, RowStatus
+ FROM SNMPv2-TC
+InterfaceIndex, ifIndex
+ FROM IF-MIB
+begemot
+ FROM BEGEMOT-MIB;
+
+begemotHast MODULE-IDENTITY
+LAST-UPDATED 20130413Z
+ORGANIZATION FreeBSD
+CONTACT-INFO
+ Mikolaj Golub
+
+Postal:Bluhera 27v 11
+ 61146 Kharkiv
+ Ukraine
+
+Fax: N/A
+
+E-Mail:troc...@freebsd.org
+DESCRIPTION
+ The Begemot MIB for managing HAST.
+REVISION 20130413Z
+DESCRIPTION
+ Initial revision.
+::= { begemot 220 }
+
+begemotHastObjects OBJECT IDENTIFIER ::= { begemotHast 1 }
+
+-- -- --
+-- Configuration parameters
+-- -- --
+
+hastConfig OBJECT IDENTIFIER ::= { begemotHastObjects 1 }
+
+hastConfigFile OBJECT-TYPE
+SYNTAX OCTET STRING
+MAX-ACCESS read-only
+STATUS current
+DESCRIPTION
+ HAST configuration file location.
+::= { hastConfig 1 }
+
+-- -- --
+-- Resource Table
+-- -- --
+hastResourceTable OBJECT-TYPE
+SYNTAX SEQUENCE OF HastResourceEntry
+MAX-ACCESS not-accessible
+STATUS current
+DESCRIPTION
+ A table containing information about all HAST resources.
+::= { begemotHastObjects 2 }
+
+hastResourceEntry OBJECT-TYPE
+SYNTAX HastResourceEntry
+MAX-ACCESS not-accessible
+STATUS current
+DESCRIPTION
+ Table entry that describes one HAST resource.
+INDEX { hastResourceIndex }
+::= { hastResourceTable 1 }
+
+HastResourceEntry ::= SEQUENCE {
+hastResourceIndex
Re: svn commit: r250379 - in head/usr.sbin/bsnmpd/modules: . snmp_hast
On Wed, May 8, 2013 at 1:03 PM, Mikolaj Golub troc...@freebsd.org wrote: Author: trociny Date: Wed May 8 20:03:37 2013 New Revision: 250379 URL: http://svnweb.freebsd.org/changeset/base/250379 Log: HAST module for bsnmpd(1). Reviewed by: harti, pjd MFC after:2 weeks This breaks world on just about everything other than i386, and it is technically broken there too but doesn't actually cause a build failure. You cannot link a .so file against a non-pic library, libl.a in this case. === usr.sbin/bsnmpd/modules/snmp_hast (all)^M /usr/obj/usr/src/tmp/usr/bin/ld: /usr/obj/usr/src/tmp/usr/lib/libl.a(libyywrap.o ): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC^M /usr/obj/usr/src/tmp/usr/lib/libl.a: could not read symbols: Bad value^M *** [snmp_hast.so.6] Error code 1^M -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r250379 - in head/usr.sbin/bsnmpd/modules: . snmp_hast
On Wed, May 8, 2013 at 4:25 PM, Peter Wemm pe...@wemm.org wrote: On Wed, May 8, 2013 at 1:03 PM, Mikolaj Golub troc...@freebsd.org wrote: Author: trociny Date: Wed May 8 20:03:37 2013 New Revision: 250379 URL: http://svnweb.freebsd.org/changeset/base/250379 Log: HAST module for bsnmpd(1). Reviewed by: harti, pjd MFC after:2 weeks This breaks world on just about everything other than i386, and it is technically broken there too but doesn't actually cause a build failure. You cannot link a .so file against a non-pic library, libl.a in this case. === usr.sbin/bsnmpd/modules/snmp_hast (all)^M /usr/obj/usr/src/tmp/usr/bin/ld: /usr/obj/usr/src/tmp/usr/lib/libl.a(libyywrap.o ): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC^M /usr/obj/usr/src/tmp/usr/lib/libl.a: could not read symbols: Bad value^M *** [snmp_hast.so.6] Error code 1^M Hmm. It seems clang optimizes something away that gcc doesn't. When building with clang the problem doesn't show up. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r250379 - in head/usr.sbin/bsnmpd/modules: . snmp_hast
On Wed, May 08, 2013 at 04:44:54PM -0700, Peter Wemm wrote: Hmm. It seems clang optimizes something away that gcc doesn't. When building with clang the problem doesn't show up. This is becoming more and more common of a problem... :( Glen pgp9cCONqb8UF.pgp Description: PGP signature
