Re: bind fails with sig11 on start / pthread failure on ARM?
On Tue, 16 Feb 2010 19:39:51 +0100 Bernd Walter mentioned: > > Do we have a general threading problem on ARM? > I don't think so. I used a lot of threaded applications on arm, and they worked fine. However, this might be some obscure bug. -- Stanislav Sedov ST4096-RIPE pgptG2mf5LXSI.pgp Description: PGP signature
Re: Results of BIND RFC
On Thu, 01 Apr 2010 15:16:59 -0700 Doug Barton mentioned: > > Of course this change will have some costs. Users of named who rely on > the current defaults will have some change management to deal with, > however the costs will be minimal. The one area that has come up > repeatedly in previous discussions about this topic is that users like > having access to the command line tools dig, host, and nslookup. To deal > with that issue I will be creating a bind-tools port so that those who > want just those tools can easily add them, without the overhead of the > rest of the BIND suite. If anyone has suggestions for other BIND tools > that should be included in the port, please let me know. Hey, Doug! While it certainly might make sense to drop BIND out of the base, I'm not sure dropping bind tools as well from it is the best decision. How hard it will be to continue maintaining bind tools inside the base (so the critical ones like dig and nslookup still will be available), while moving the rest of it (the server itself and supporting tools) to the port? -- Stanislav Sedov ST4096-RIPE pgpvEm8qc8zyJ.pgp Description: PGP signature
Re: Results of BIND RFC
On Fri, 02 Apr 2010 17:26:13 +0900 Randy Bush mentioned: > > i don't mind if dig, doc, et alia are not in base, as long as they are a > separate port from the bind hippo. > The major benefit of having them in the base is the ability to cross-compile them when building the distribution for another platform. Ports doesn't support cross-compilation yet, and it would be a pity to find yourself bootstrapping another tiny arm platform and having to use ports to have a usable system. -- Stanislav Sedov ST4096-RIPE ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Results of BIND RFC
On Fri, 02 Apr 2010 08:55:07 + "Poul-Henning Kamp" mentioned: > In message <20100402013353.f544e8ad.s...@freebsd.org>, Stanislav Sedov writes: > >On Fri, 02 Apr 2010 17:26:13 +0900 > >Randy Bush mentioned: > > >Ports doesn't support cross-compilation yet, > >and it would be a pity to find yourself > >bootstrapping another tiny arm platform and > >having to use ports to have a usable system. > > The result of the RFC was that bind is not a mandatory component > to make "a usable system", so you argument suffers from bad logic. > > The fact that you want BIND on your arm, is no different from > somebody else wanting postfix on a MIPS. Sorry, I think I was not clear enough. What I actually want is to have a couple of the important tools in the base while moving everything also in ports. By important tools I mean nslookup (and maybe dig), and at least the first one is cruicial for the system bringup. That one is also nice to have on the livecd, which currently includes (I believe) only the base system. -- Stanislav Sedov ST4096-RIPE ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: UMA initialization failure with 48 core ARM64
> On May 15, 2015, at 11:30 AM, Michał Stanek wrote: > > Hi, > > I am experiencing an early failure of UMA on an ARM64 platform with 48 > cores enabled. I get a kernel panic during initialization of VM. Here is > the boot log (lines with 'MST:' are my own debug printfs). > > Copyright (c) 1992-2015 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 11.0-CURRENT #333 52fd91e(smp_48)-dirty: Fri May 15 18:26:56 CEST > 2015 > > mst@arm64-prime:/usr/home/mst/freebsd_v8/obj_kernel/arm64.aarch64/usr/home/mst/freebsd_v8/kernel/sys/THUNDER-88XX > arm64 > FreeBSD clang version 3.6.0 (tags/RELEASE_360/final 230434) 20150225 > MST: in vm_mem_init() > MST: in vmem_init() with param *vm == kernel_arena > MST: in vmem_xalloc() with param *vm == kernel_arena > MST: in vmem_xalloc() with param *vm == kmem_arena > panic: mtx_lock() of spin mutex (null) @ > /usr/home/mst/freebsd_v8/kernel/sys/kern/subr_vmem.c:1165 > cpuid = 0 > KDB: enter: panic > [ thread pid 0 tid 0 ] > Stopped at 0xff80001f4f80: > > The kernel boots fine when MAXCPU is set to 30 or lower, but the error > above always appears when it is set to a higher value. > > The panic is triggered by a KASSERT in __mtx_lock_flags() which is called > with the macro VMEM_LOCK(vm) in vmem_xalloc(). This is line 1143 in > subr_vmem.c (log shows different line number due to added printfs). > It looks like the lock belongs to 'kmem_arena' which is uninitialized at > this point (kmeminit() has not been called yet). > > While debugging, I tried modifying VM code as a quick workaround. I > replaced the number of cores to 1 wherever mp_ncpus, mp_maxid or MAXCPU > (and others) are read. This, I believe, limits UMA per-cpu caches to just > one, while the rest of the OS (scheduler, etc) sees all 48 cores. > In addition, I changed UMA_BOOT_PAGES in sys/vm/uma_int.h to 512 (default > was 64). > With these tweaks, I got a successful (but not really stable) boot with 48 > cores. Of course these are dirty hacks and a proper solution is needed. > > I am a bit surprised that the kernel fails with MAXCPU==48 as the amd64 > arch has this value set to '256' and I have read posts that other platforms > with even more cores have worked fine. Perhaps I need to tweak some other > VM parameters, apart from UMA_BOOT_PAGES (AKA vm.boot_pages), but I am not > sure how. > > I included a full stacktrace and a more verbose log (with UMA_DEBUG macros > enabled) in the attachment. There is also a diff of the hacks I used while > debugging. > > Hi, Michal! It looks like the log attachment didn’t make it though the mailing list. Can you please resend it again? The panic suggests that a mutex was left uninitialized... -- ST4096-RIPE ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ports on 10.0-CURRENT: r226027 is incorrect fix
On Sat, 8 Oct 2011 02:03:37 +0300
Mykola Dzham mentioned:
> Hi!
> r226027 fix ( ... s/freebsd1\*)/SHOULDNOTMATCHANYTHING1)/ ...) is
> incorrect: this commit breaks metaports building:
>
> # cd /usr/ports/print/teTeX && sudo make clean all
> ===> Cleaning for teTeX-3.0_5
> ===> License check disabled, port has not defined LICENSE
> ===> Found saved configuration for teTeX-3.0_2
> ===> Extracting for teTeX-3.0_5
> ===> Patching for teTeX-3.0_5
> ===> Configuring for teTeX-3.0_5
> find /tmp/ports/usr/ports/print/teTeX/work/teTeX-3.0 -type f \( -name
> config.libpath -o -name config.rpath -o -name configure -o -name libtool.m4
> \) -exec sed -i '' -e 's/freebsd1\*)/SHOULDNOTMATCHANYTHING1)/' -e
> 's/freebsd\[123\]\*)/SHOULDNOTMATCHANYTHING2)/' {} +
> find: /tmp/ports/usr/ports/print/teTeX/work/teTeX-3.0: No such file or
> directory
> *** Error code 1
>
> Stop in /usr/ports/print/teTeX.
> *** Error code 1
>
> Stop in /usr/ports/print/teTeX.
>
> I think this commit should be reverted. Using UNAME_r is less destructive
> work around
>
Hi!
I just committed the fix that checks if the ${WRKSRC} directory exists firts.
Thanks!
--
Stanislav Sedov
ST4096-RIPE
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ports on 10.0-CURRENT: r226027 is incorrect fix
On Sat, 8 Oct 2011 18:35:13 +0100 Chris Rees mentioned: > > Last I heard, portmgr explicitly disapproved of this fix-- have I missed > something??? Erwin specifically said not to do it. > > Since when can anyone just commit stuff to bsd.port.mk, regardless of its > location? > > This is a bad solution, please revert it or I will when I get back. We're > going to end up being asked to support it on ports@ otherwise. > You certianly missed something, including the rationale behind the portmgr@ descision of not committing to the ports tree (!) bsd.port.mk. Go find some useful work to do like deleting old ports or whatever. You might want to consider deleting all mine ports, as I'm not going to support them anymore (after you backed out this fix without approval I don't have a working ports tree anymore on any of my 3 workstations). -- Stanislav Sedov ST4096-RIPE () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ports on 10.0-CURRENT: r226027 is incorrect fix
On Mon, 10 Oct 2011 12:04:19 -0700 Stanislav Sedov mentioned: > On Sat, 8 Oct 2011 18:35:13 +0100 > Chris Rees mentioned: > > > > > Last I heard, portmgr explicitly disapproved of this fix-- have I missed > > something??? Erwin specifically said not to do it. > > > > Since when can anyone just commit stuff to bsd.port.mk, regardless of its > > location? > > > > This is a bad solution, please revert it or I will when I get back. We're > > going to end up being asked to support it on ports@ otherwise. > > > > You certianly missed something, including the rationale behind the portmgr@ > descision of not committing to the ports tree (!) bsd.port.mk. Go find > some useful work to do like deleting old ports or whatever. You might want > to consider deleting all mine ports, as I'm not going to support them anymore > (after you backed out this fix without approval I don't have a working ports > tree anymore on any of my 3 workstations). > Quoting myself. Sorry to all if this sounded rude, I might have overreacted. I didn't meant to be personal, it's just the whole situation is disappointing. -- Stanislav Sedov ST4096-RIPE () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [UPDATE] Re: Update on ports on 10.0
On Mon, 17 Oct 2011 15:35:51 +0300 Ion-Mihai Tetcu mentioned: > > > Here's a little status update: > We iterated through a few -exp runs (basically for ports/161404 -- > committed and ports/161431 -- skv@ any problem with it?). With those two > we can build around 7k packages. The majority of the rest can't be built > because of a few high profile ports that don't package: expat (6581), > curl (975), jpeg(5057), lcms(1080), libiconv(11180), libltdl(1187), > libogg(1947), pcre(5737), python27(5935). > > http://pointyhat.freebsd.org/errorlogs/i386-10-latest/ > > What we'd like to do next is see how many ports we can package after > individually fixing those above. This will require a few other -exps > since undoubtedly we'll find other highly-depended-on ports broken that > weren't tried because of the blockers above. > It doesn't require an exp-run to understand that you won't move much further with just fixinng these ports. If you want, I and other people can tell you exactly what will break next (libX* being some of them). There's no way you can work this aroun by fixing few ports by hand: virtually any ports using libtool (and I mean using libtool, not having it in depends list) contains an embedded version of it inside "configure" and thus requires patching similar to the patch Ed, Doug and other people proposed. Actually, that sed one-liner fixed like 99% of the ports in tree, excluding some complex ones (like GCC). So why not commit that patch as a KNOB to bsd.port.mk like it was initially proposed and let people use it in individual ports makefiles to fix them (and portmgr@ can commit the initial bunch of these knobs)? This is the easiest thing you can do now, and you will be able to abandon it when the better solution is available (which is unlikely). WRT your "submit upstream" comment, personanlly, I'd argue against this: this is not the upstream maintainer's problem, it the buggy tools they use to generate the configure scripts, so until the fixed version of libtool is available in all major distributions and widely installed, they're not going to replace it or patch locally. Given the debian/ubuntu release schedule, this is not going to happen earlier that 1-2 years from now, and your patches/requests sent could potentially cause them to abandon FreeBSD support altogether requiring a lot of work to maintain which will be totally understandable. -- Stanislav Sedov ST4096-RIPE () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [head tinderbox] failure on mips/mips
On Thu, 22 Mar 2012 18:06:28 GMT FreeBSD Tinderbox mentioned: > TB --- 2012-03-22 17:20:36 - tinderbox 2.9 running on > freebsd-current.sentex.ca > TB --- 2012-03-22 17:20:36 - starting HEAD tinderbox run for mips/mips > TB --- 2012-03-22 17:20:36 - cleaning the object tree > TB --- 2012-03-22 17:20:37 - cvsupping the source tree > TB --- 2012-03-22 17:20:37 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca > /tinderbox/HEAD/mips/mips/supfile > TB --- 2012-03-22 17:20:53 - building world > TB --- 2012-03-22 17:20:53 - CROSS_BUILD_TESTING=YES > TB --- 2012-03-22 17:20:53 - MAKEOBJDIRPREFIX=/obj > TB --- 2012-03-22 17:20:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2012-03-22 17:20:53 - SRCCONF=/dev/null > TB --- 2012-03-22 17:20:53 - TARGET=mips > TB --- 2012-03-22 17:20:53 - TARGET_ARCH=mips > TB --- 2012-03-22 17:20:53 - TZ=UTC > TB --- 2012-03-22 17:20:53 - __MAKE_CONF=/dev/null > TB --- 2012-03-22 17:20:53 - cd /src > TB --- 2012-03-22 17:20:53 - /usr/bin/make -B buildworld > >>> World build started on Thu Mar 22 17:20:54 UTC 2012 > >>> Rebuilding the temporary build tree > >>> stage 1.1: legacy release compatibility shims > >>> stage 1.2: bootstrap tools > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3: cross tools > >>> stage 4.1: building includes > >>> stage 4.2: building libraries > >>> stage 4.3: make dependencies > >>> stage 4.4: building everything > [...] > cc -O -pipe -G0 > -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/asn1 > -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/roken > -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kfd/../../include -std=gnu99 -c > /src/kerberos5/libexec/kfd/../../../crypto/heimdal/appl/kf/kfd.c > cc -O -pipe -G0 > -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/asn1 > -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/roken > -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kfd/../../include -std=gnu99 -o > kfd kfd.o -lkrb5 -lroken -lasn1 -lcrypto -lcrypt > /obj/mips.mipsel/src/kerberos5/libexec/kfd/../../lib/libvers/libvers.a > gzip -cn /src/kerberos5/libexec/kfd/../../../crypto/heimdal/appl/kf/kfd.8 > > kfd.8.gz > ===> kerberos5/libexec/kimpersonate (all) > cc -O -pipe -G0 > -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/hx509 > -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/asn1 > -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/roken > -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/sl -I. > -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kimpersonate/../../include > -std=gnu99 -c > /src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/kuser/kimpersonate.c > cc -O -pipe -G0 > -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/hx509 > -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/asn1 > -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/roken > -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/sl -I. > -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kimpersonate/../../include > -std=gnu99 -o kimpersonate kimpersonate.o -lkafs5 -lkrb5 -lheimntlm -lroken > -lasn1 -lcrypto -lcrypt > /obj/mips.mipsel/src/kerberos5/libexec/kimpersonate/../../lib/libvers/libvers.a > /obj/mips.mipsel/src/tmp/usr/bin/ld: > /obj/mips.mipsel/src/tmp/usr/lib/libkafs5.so symbol number 13 references > nonexistent SHT_SYMTAB_SHNDX section > /obj/mips.mipsel/src/tmp/usr/lib/libkafs5.so: could not read symbols: File > format not recognized > *** Error code 1 > Hi! This is due to the bug in binutils which we're working on fixing in base binutils. I added a workaround to the libkafs5 Makefile, but tinderbox is using a deprecated TARGET_ARCH=mips which does not enable that workaround. Should we switch tinderbox to use mips.mipseb or mips.mipsel instead? -- Stanislav Sedov ST4096-RIPE () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [head tinderbox] failure on mips/mips
On Thu, 22 Mar 2012 14:46:51 -0700 Juli Mallett mentioned: > On Thu, Mar 22, 2012 at 14:39, Stanislav Sedov wrote: > > Hi! > > > > This is due to the bug in binutils which we're working on fixing in base > > binutils. > > I added a workaround to the libkafs5 Makefile, but tinderbox is using a > > deprecated > > TARGET_ARCH=mips which does not enable that workaround. Should we switch > > tinderbox to > > use mips.mipseb or mips.mipsel instead? > > Please don't switch it as "mips" will be the new spelling of "mipseb" > in the very near future. Ah, ok. So is it a good idea to modify my condition in the linkafs5 Makefile to apply the workaround for mips.mips as well? Thanks! -- Stanislav Sedov ST4096-RIPE () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [head tinderbox] failure on mips/mips
On Mar 27, 2012, at 11:14 AM, John Baldwin wrote: > I got this exact error for my own 'make tinderbox' for both mipsel and mipseb > worlds yesterday. Anyone have any ideas? Is this some sort of binutils bug? Hmm, this shouldn't happen on mipsel/mipseb as I've put a workaround in the libkafs5 Makefile. Can you, please, upload the full build log somewhere, or post the part where it links libkafs5? The problem there is that when linking libkafs5 if we link agains libkrb5 we trigger the binutils bug which create the bad symbol. -- ST4096-RIPE ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: There is a known problem with MIPS tinderbox.
On Thu, 5 Apr 2012 12:39:00 -0700 Juli Mallett mentioned: > On Thu, Apr 5, 2012 at 12:28, Doug Barton wrote: > > But as always, if someone comes up with an actual problem related to the > > [BIND] update I'm happy to address it. > > The MIPS tinderbox build is currently broken. This is related to a > binutils bug for which a workaround was committed to head. For some > reason, the workaround seems to be sufficient for universe done > independently, but not the tinderbox. > > There is a fix for binutils which is known, but the fix was made after > the GPLv3 switch. HJ Lu, who made the change, has been contacted > about making the change available under GPLv2, but so far has not > replied. Independently, jchandra@ is investigating the problem in > binutils and attempting to come up with a fix from scratch. > What I still cannot understand is that why my workaround doesn't work on tinderbox and for some people builds. It should disable linking agains libasn1 for libkafs5 completely on mips which is the source of the problem in libkafs5. -- Stanislav Sedov ST4096-RIPE () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [head tinderbox] failure on mips/mips
On Thu, 5 Apr 2012 16:35:06 -0700 Garrett Cooper mentioned: > 2012/4/5 Dag-Erling Smørgrav : > > Garrett Cooper writes: > >> From what I saw it seems to be localized to the tinderbox host > >> environment because I don't run into this issue with a copy of CURRENT > >> compiled from r233913 sources. > > > > There is nothing special about the tinderbox host environment, it's a > > quad-core Phenom running 8.3-STABLE and you can see the exact commands > > and environment variables used at the top of the log. > > Forgot a key piece of info. My VM that this works on is i386, not > amd64. I assume that's a trigger? Actually, no, I'm don't even have any i386 machines. I guess it's just somewhat intermittent. -- Stanislav Sedov ST4096-RIPE () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: There is a known problem with MIPS tinderbox.
On Apr 5, 2012, at 11:08 PM, Jayachandran C. wrote: > > > The asn1 library has a export map containing 'global: *', this exports > two symbols _fdata and _ftext versioned. When libkafs5 is linked, > these symbols confuse the bfd code and the entries corresponding to > theses (index 13, and 16) are left un-initialized. > > One workaround I see is to change the export 'global: *' in > kerberos5/lib/libasn1 to the actual list of exported symbols. > Thanks. What I'm also trying right now is to add a version map to the libkafs -- this might help binutils to link it properly as well. If it fails, we can try adding a proper one for libasn1. -- ST4096-RIPE ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: There is a known problem with MIPS tinderbox.
On Fri, 6 Apr 2012 13:08:12 +0530
"Jayachandran C." mentioned:
> On Fri, Apr 6, 2012 at 12:01 PM, Stanislav Sedov wrote:
> >
> > On Apr 5, 2012, at 11:08 PM, Jayachandran C. wrote:
> >>
> >>
> >> The asn1 library has a export map containing 'global: *', this exports
> >> two symbols _fdata and _ftext versioned. When libkafs5 is linked,
> >> these symbols confuse the bfd code and the entries corresponding to
> >> theses (index 13, and 16) are left un-initialized.
> >>
> >> One workaround I see is to change the export 'global: *' in
> >> kerberos5/lib/libasn1 to the actual list of exported symbols.
> >>
> >
> > Thanks. What I'm also trying right now is to add a version map to the
> > libkafs -- this might help binutils to link it properly as well. If it
> > fails, we can try adding a proper one for libasn1.
>
> The libasn1 workaround is here:
> http://people.freebsd.org/~jchandra/libasn1.diff
>
Thanks!
My idea of adding a version map to libkafs worked as well.
Can you, please, test if it fixes the issue for you?
It seems to be a less complicated way to solve it.
Index: kerberos5/lib/libkafs5/version.map
===
--- kerberos5/lib/libkafs5/version.map (revision 0)
+++ kerberos5/lib/libkafs5/version.map (revision 0)
@@ -0,0 +1,19 @@
+HEIMDAL_KAFS5_1.0 {
+ global:
+ k_afs_cell_of_file;
+ k_hasafs;
+ k_hasafs_recheck;
+ k_pioctl;
+ k_setpag;
+ k_unlog;
+ kafs_set_verbose;
+ kafs_settoken5;
+ kafs_settoken_rxkad;
+ krb5_afslog;
+ krb5_afslog_home;
+ krb5_afslog_uid;
+ krb5_afslog_uid_home;
+ krb5_realm_of_cell;
+ local:
+ *;
+};
Index: kerberos5/lib/libkafs5/Makefile
===
--- kerberos5/lib/libkafs5/Makefile (revision 233932)
+++ kerberos5/lib/libkafs5/Makefile (working copy)
@@ -1,20 +1,13 @@
# $FreeBSD$
LIB= kafs5
-LDADD= -lasn1 -lroken
+LDADD= -lasn1 -lroken -lkrb5
+LDFLAGS= -Wl,--no-undefined
DPADD= ${LIBASN1} ${LIBKRB5} ${LIBROKEN}
INCS= kafs.h
MAN= kafs5.3
+VERSION_MAP= ${.CURDIR}/version.map
-#
-# Linking with libkrb5 uncovers a bug in binutils.
-# See
http://repo.or.cz/w/binutils.git/commit/ee05170bf71819c99cb5a36a44735c231ae03c56
.
-#
-.if ${MACHINE} != "mips"
-LDADD+=-lkrb5
-LDFLAGS= -Wl,--no-undefined
-.endif
-
MLINKS=kafs5.3 k_afs_cell_of_file.3 \
kafs5.3 k_hasafs.3 \
kafs5.3 k_pioctl.3 \
--
Stanislav Sedov
ST4096-RIPE
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: libprocstat compile error
On Thu, 12 May 2011 19:38:20 +0200 Randy Bush mentioned: > same here > > ===> lib/libprocstat (depend) > rm -f .depend > mkdep -f .depend -a-I. -I/usr/src/lib/libprocstat -D_KVM_VNODE -DZFS > /usr/src/lib/libprocstat/cd9660.c /usr/src/lib/libprocstat/common_kvm.c > /usr/src/lib/libprocstat/libprocstat.c > /usr/src/lib/libprocstat/msdosfs.c /usr/src/lib/libprocstat/ntfs.c > /usr/src/lib/libprocstat/nwfs.c /usr/src/lib/libprocstat/smbfs.c > /usr/src/lib/libprocstat/udf.c > /usr/src/lib/libprocstat/nwfs.c:44:26: error: fs/nwfs/nwfs.h: No such > file or directory > /usr/src/lib/libprocstat/nwfs.c:45:31: error: fs/nwfs/nwfs_node.h: No > such file or directory > mkdep: compile failed > *** Error code 1 > Hi! Sorry for the breakage! Do you have any special configuration in make.conf? Can you, please, send me your make.conf and kernel configuration file? Thanks! -- Stanislav Sedov ST4096-RIPE () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: libprocstat compile error
Hi! I just committed a fix for this. It should build fine now. -- Stanislav Sedov ST4096-RIPE () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Loading drivers via kldload
On Thu, 11 Aug 2011 17:08:30 -0700 David Somayajulu mentioned: > Hi All, > While loading PCIe based HBA drivers via kldload, does FreeBSD expect a valid > (i.e., non-zero) PCI subsystem Vendor and Device IDs? > It depends on the specific driver. FreeBSD doesn't check for the PCI ID in general. Usually, drivers contains a routine that check if this driver can be used with that hardware based on the PCI ID. -- Stanislav Sedov ST4096-RIPE () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
