Re: ldconfig finding libraries, but ld is not.
On Fri, Nov 12, 1999 at 12:24:53PM -0800, Duane H. Hesser wrote: > A few still have 'local' hardwired in, but after many years of ... > The X11 situation is not quite as rosy; there have been quite a > few which needed hand patching. The problem seems to be a lot of > Imakefiles with BINDIR, INCROOT, MANPATH, and USRLIBDIR hard-coded > to use /usr/local. Even so, hand-patching these has not been much > of a burden. Please send a PR on these. We want to make everything PREFIX clean. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: ldconfig finding libraries, but ld is not.
On Thu, Nov 11, 1999 at 05:34:23PM -0800, Mike Meyer wrote: > Except, of course, that /usr/local/lib *does* get special treatment! > It's listed in ldconfig_paths (and the aout subdir > ldconfig_paths_aout), along with /usr/X11R6/lib & > /usr/lib/compat. None of those are part of the OS, though all are part > of the distribution. > This seems a tad inconsistent. We make sure that the person installing Yes, but ldconfig_paths is in the rc.conf configuration file. -L paths are hardcoded and compiled into GCC and friends. The user can change ldconfig_paths as they need to. There isn't an easy way for them to change the auto -L list. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: ldconfig finding libraries, but ld is not.
On Thu, Nov 11, 1999 at 03:14:04PM -0800, Mike Meyer wrote: > ;->It belongs in /usr/local. > > I don't agree. Things being maintainted and supported locally belong > in /usr/local. Ports and packages come on the distribution, and you go > back to the same channels for support as you do for core parts of that > distribution. I'll have to agree with you here. I think it was a grave mistake for FreeBSD to install packages into /usr/local/. We should have used /usr/pkg/ as NetBSD did. As GCC maintainer, I will not add /usr/local/lib to the list of automatically looked places in the base compiler. For one it isn't PREFIX clean. [ Please remember one can set PREFIX=/usr/pkg and build the Ports Collection ] -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Solution to my 3.3-RELEASE panics!
> Thomas David Rivers wrote: > > > I'll have to attribute this to the "nut behind > > the wheel." Apparently, I must have done a > > config with some option (likely DDB) on and not > > done a clean build... (i.e. didn't do a `make clean; make') > > You shouldn't need to make clean... make depend; make should be enough. > > -- > Ben Smithurst| PGP: 0x99392F7D > [EMAIL PROTECTED] | key available from keyservers and > | [EMAIL PROTECTED] > I'm not sure. I'm _guessing_ this is what happened. config a brand kernel without options DDB. do a make - boot and run that kernel - all is fine. then, change the config file and add options DDB. Then, do make depend; make (which I believe is what I did.) But - some of the files that need to know that DDB is now defined are not recompiled (I'm guessing, I haven't checked on this.) - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: ldconfig finding libraries, but ld is not.
Mike and Paul I agree with both of you (at least conceptually), regarding installation locations of software (the topic here has wandered a bit from the original Subject: line). I think your positions are not so far apart, differing only in detail. It is certainly (in my view) useful to keep optional software separate from the base system. Personally, I find it convenient (especially at upgrade time) to keep separate 1) the 'base' system 2) the 'ports' system 3) locally ported/generated software By default, the ports system combines 2) and 3), but is flexible enough to allow them to be separated rather easily (for the most part) simply by adjusting the variables LOCALBASE and X11BASE in /etc/make.conf. I have read most of this thread, and have been surprised that no one mentioned this. It is in the forefront of my mind because I spent some time this summer in a 'major upgrade' of my system, with a fresh install of FreeBSD 3.2 stable *and* RedHat Linux 6.0 on a new 9 gig ultra-wide Atlas drive (for a while there, I had a 'quad boot' system). The Linux system is just one big mass (on one filesystem); there is no 'base' system, just a kernel, an init, and everything else, all mixed together. On the FreeBSD system, though, I spent some time re-designing the filesystem layout (since it's possible to *have* a filesystem layout) to support the above separation. On the 'old' FreeBSD system, ports and locally installed software were intermixed so that it was difficult to know which was which. The switch to elf made it seem reasonable to re-install everything in any case. Here is what I've done. It may not appeal to you, but the point is that the ports system is flexible enough to let each of us do our own thing. Those who see no advantage to separating optional software ported 'elsewhere' and home-grown ports or sources need do nothing. The rest of us only need to do a couple of quick edits of make.conf and the ports supfile, and maybe a couple of 'mkdirs'. I've gone so far as to make separate filesystems for 'ports' and 'local'. /dev/da0s1d 3181934 1488777 143860351%/usr/local /dev/da0s1f 2087950 959140 96177450%/usr/ports The result is the usual: /usr/local/bin /usr/local/lib /usr/local/include /usr/local/src ...etc.. where I put stuff I have personally mangled. LOCALBASE is set to '/usr/ports' (the default is '/usr/local') so there is also: /usr/ports/bin /usr/ports/lib /usr/ports/include /usr/ports/src/ports ...etc... (the latter path really should be just '/usr/ports/src', but cvsup is rather insistent about appending 'ports' to the supfile 'prefix', so what the heck) I have also installed the latest XFree86 distribution, which I also wish to keep separate. /dev/da1s2e514202 329113 14395370%/usr/X11R6 I set X11BASE to '/usr/ports/X11R6', so that X11 ports are also kept separate from the 'stock' distribution (combined with all other ports). THE RESULTS of this have been encouraging, so far (I am not quite finished yet, working at it in fits and starts, with a lot of the old stuff still around; the framework is in place though, and the next upgrade (circa 2039 :-) will be easier). Most non-X11 ports honor LOCALBASE just fine; works like a charm. A few still have 'local' hardwired in, but after many years of hand-porting USENET distributions, etc. I'm not about to complain about an occasional need to edit a PREFIX in a makefile. The ports maintainers have more than once indicated a willingness to fix any reported problems of this nature, but there have been surprisingly few of these. I will go through my notes one day and send them what I've managed to record; until then, no complaints from *here*. The X11 situation is not quite as rosy; there have been quite a few which needed hand patching. The problem seems to be a lot of Imakefiles with BINDIR, INCROOT, MANPATH, and USRLIBDIR hard-coded to use /usr/local. Even so, hand-patching these has not been much of a burden. I should note that I also provide a /usr/local/X11R6 dirctory, although the only things there so far are some TrueType fonts. On the *original* topic of this thread (having to do with compiler/linker paths) it *would* be nice if configure scripts (Imakefiles) took account of the possiblity that LOCALBASE (X11BASE) might not be /usr/local, and were prepared to look both places, and add the necessary '-I' and '-L' flags. I would add my voice to any movement which might arise aimed at changing the default LOCALBASE for ports away from '/usr/local', although I do not find it strange in the least that the developers of the ports system chose that prefix in the beginning. The '/usr/local' convention arose rather strongly wayy back in the mid eighties and has gained status in many minds as a (de facto) 'standard'. I would argue, though, that the extraordinarily useful 'ports' system is a slightly different animal th
subscribe
subscribe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Slapd (LDAP)
To answer my own question: In /usr/ports/net/ldap/work/ldap-3.3/doc/guides/guide.pdf (administrators guide) There is everything you'd ever need.for sladp Thanks anyway to those who tried to help. Greg My original question was: > Is any one using the slapd (ldap) services, if so can they point me to a > good reference site, as all the man pages refer to the Ldap Administrators > Guide :( To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Mounting an ATAPI-CDROM ?
Gregory Bond wrote in list.freebsd-stable: > > wdc0 ist the IDE controller, not the CD-ROM drive. > > Look for acd0 (ATAPI CD-ROM drive) in your boot messages. > > Type this command: dmesg | grep acd > > Depending on the vintage of his system, the ATAPI CD driver and corresponding > /dev/ entry have been called wcd0 and acd0 at various times, even in the life > of 3.x. That's true. However, this is the -stable mailing list, and he didn't mention the version of his OS at all, so I assumed that he has a "current" -stable, so to speak. ;-) Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Solution to my 3.3-RELEASE panics!
Thomas David Rivers wrote: > I'll have to attribute this to the "nut behind > the wheel." Apparently, I must have done a > config with some option (likely DDB) on and not > done a clean build... (i.e. didn't do a `make clean; make') You shouldn't need to make clean... make depend; make should be enough. -- Ben Smithurst| PGP: 0x99392F7D [EMAIL PROTECTED] | key available from keyservers and | [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: ldconfig finding libraries, but ld is not.
On Sun, 14 Nov 1999, mleczo wrote: > Helo > Im new to all of this > But got one question > I cant compile eggdrop on my FreeBSD 2.2.8 > When it comes to linking i got an error > ld: -ltcl no match > > Wheres the problem > PLease help me solve this > > bye > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-stable" in the body of the message > One more time casue this thiung very important to me To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: ldconfig finding libraries, but ld is not.
John Baldwin writes: ;->> The bottom line is that taking the name people have standardized on ;->> for installing *local* packages and installing system-provided ;->> packages there is a bad thing(TM). None of the solutions I used ;->> suffered from that flaw. ;->Umm, if the name /usr/local disturbs you greatly, then set PREFIX in ;->/etc/make.conf to whatever name you do like (/usr/global), etc. That's the same headache, only in a different place. The traffic on the ports list suggests that support for PREFIX isn't universal as well. Come to think of it - does the OS install let me specify what PREFIX should be when installing packages? ;->I ;->also don't see how installing 3rd party software directly under /usr so ;->that it is mixed up with system-provided software (what is in /usr that ;->comes with OS, i.e. not 3rd party software) is easier to administer. Ports and packages *do* come with the OS. When I boot from the FreeBSD floppy, it figures some stuff out about my system, ask me about some stuff - including letting me choose what packages I want to install. It then copies a bunch of stuff over the network and installs it. Some of that sofware goes in /usr; some goes in /usr/local - they *all* come from the net under the control of the installation software. ;->Then you are having to distribute a lot more and increasing your ;->network load, espeically your NFS load. To each his own I suppose. ;->Personally, I think sticking everything under the sun in /usr/bin is ;->not organized. I don't know - "executables are in /usr/bin" sounds like an organization to me :-). That's what started this. My problem is that the OS install puts software in a place that is traditionally reserved for software that didn't come with the distribution. This means you either get to deal with the headaches associated with missing software that was installed as part of the OS install and software that you added, or you get headaches when you forget to deal with it when installing softare that didn't come with the distribution (the solution of creating an area that *should* be named /usr/local, but can't), or you get headaches when you forget to deal with it when installing the packages that come with FreeBSD.
Re: ldconfig finding libraries, but ld is not.
On Sun, 14 Nov 1999, mleczo wrote: > Helo > Im new to all of this > But got one question > I cant compile eggdrop on my FreeBSD 2.2.8 > When it comes to linking i got an error > ld: -ltcl no match > > Wheres the problem > PLease help me solve this This would have been better suited for -questions, but here we go. You need to instal the TCL8 port to compile eggdrop. See /usr/ports/lang/tcl81/ or install the package from /stand/sysinstall. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: ldconfig finding libraries, but ld is not.
On 11-Nov-99 Mike Meyer wrote: > John Baldwin writes: > ;->On 11-Nov-99 Mike Meyer wrote: > ;->> I still curse at regular intervals at the ports/packages > collection > ;->> installing things in /usr/local. That means I need another place > for > ;->> things that I maintain, instead of came with FreeBSD. Putting > ;->> everything in /usr is one such solution. /opt is another (but > having > ;->> everything have it's own hierarchy pretty much sucks). > ;->Try maintaining a lab of 40-80 identical machines. Then imagine > ;->distributing /usr/local and /usr/X11R6 via NFS. Then you only > have to > ;->install the package on one machine to install it everywhere. That > ;->doesn't work when installed under /usr. Are you enlightened yet? > > Yes, but not about what you hoped. Back when I did that kind of > thing, > I did a better job than that. Let's see - off the top of my head, > I've network mounted /usr (the Linux solution to this problem), /opt > (the Solaris solution), and used rdist, rsync and perforce to do the > distribution. > > The bottom line is that taking the name people have standardized on > for installing *local* packages and installing system-provided > packages there is a bad thing(TM). None of the solutions I used > suffered from that flaw. Umm, if the name /usr/local disturbs you greatly, then set PREFIX in /etc/make.conf to whatever name you do like (/usr/global), etc. Also, ports are not system-provided packages, they are 3rd party software. I also don't see how installing 3rd party software directly under /usr so that it is mixed up with system-provided software (what is in /usr that comes with OS, i.e. not 3rd party software) is easier to administer. Then you are having to distribute a lot more and increasing your network load, espeically your NFS load. To each his own I suppose. Personally, I think sticking everything under the sun in /usr/bin is not organized. >-- http://www.cslab.vt.edu/~jobaldwi/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
CPIO message.
cpio: Read error at byte 0 in file ./proc/3250/map, padding with zeros cpio: File ./proc/3250/etype shrunk by 64 bytes, padding with zeros cpio: Read error at byte 0 in file ./proc/3249/map, padding with zeros While doing a cpio backup the above message appears. I know it is the process file system, and that my backup is NOT failing, but I just can not get rid of the message. I have tried: cd / find . \! -name "./proc/*" -depth -print | cpio -oBO /dev/tape -H NEWC BUT that still tries to backup the /proc directory what next? Greg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message