Custom Search
|
Date: December 31, 2006
From: Ken Moffat <zarniwhoop@xxxxxxxxxxxx>
In-reply-to:
<20061231143412.GA4457@deepthought
>
References:
<20061231132446.10484.qmail@xxxxxxxxxxxxxxxxxxxxxxxxx> <20061231143412.GA4457@deepthought
>
On Sun, Dec 31, 2006 at 02:34:12PM +0000, Ken Moffat wrote: > > I'm finishing off a desktop build on LFS svn (i686) using glibc-2.5 > (against 2.6.18.x kernel headers), and on that the glibc nptl tests > failed badly although the resulting desktop system seems to be ok. I > guess that a change (kernel, headers, or toolchain) has proved the > nptl tests are fragile. I'm also guessing that glibc-2.5 has not had > a vast amount of testing yet. > Probably something in the c++ compiler - the failures are mostly a mixture of 'exception not caught' and 'cleanup handler not called'. I don't grok c++, I don't intend to follow toolchain development unless I really need to, and I couldn't find anything relevant on google, so I'll forget about this problem for the rest of the year ;-) ĸen -- das eine Mal als Tragödie, das andere Mal als Farce
Date: December 31, 2006
From: Ken Moffat <zarniwhoop@xxxxxxxxxxxx>
In-reply-to:
<b86643eb0612310627u10703ca1g258f2b550fa12860@xxxxxxxxxxxxxx>
References:
<20061231132446.10484.qmail@xxxxxxxxxxxxxxxxxxxxxxxxx> <b86643eb0612310627u10703ca1g258f2b550fa12860@xxxxxxxxxxxxxx>
On Sun, Dec 31, 2006 at 06:27:39AM -0800, Jonathan Davis wrote: > > Well, I had the same errors for the 32-bit build for x86_64-Multilib > and as far as I can tell, they haven't caused any problems. Like you, > I was unable to find anything helpful online and no one ever responded > to my post to CLFS-Support with a solution. However, as I said, I > don't think that it's actually a big problem. Sorry, your post must have slipped under my radar, maybe because I hadn't used 2.5 at the time. I could have saved writing my previous reply if I'd been a minute or two later ;-) > In the 64-bit build I got additional errors: > > make[2]: *** [/usr/src/glibc/glibc-build/libio/tst-wmemstream1.out] Error 1 > make[2]: *** [/usr/src/glibc/glibc-build/libio/tst-wmemstream2.out] Error 1 > make[2]: *** [/usr/src/glibc/glibc-build/libio/bug-wmemstream1.out] Error 1 > make[1]: *** [libio/tests] Error 2 > make[2]: [/usr/src/glibc/glibc-build/posix/annexc.out] Error 1 (ignored) > make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancel1.out] Error 1 > make[1]: *** [nptl/tests] Error 2 > make: *** [check] Error 2 > > I assume that the wmemstream errors are related to unicode which isn't > going to work on a CLFS system anyway. Thanks for sharing these, so that we know what to expect. I've got some unicode working on my recent clfs-1.0.0 systems (in X, I think we need something else to get it working at all on the console), and I think I've even got UTF-8 manpages working (amazing how many people put 'smart-quotes' into manpages in english, e.g. for smartmontools). Very possibly, the temporary system might need something, but I think all the widec support comes later (e.g. the final ncurses, vim) so it could equally be something else entirely, such as bash in the temporary system. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce
Date: December 31, 2006
From: Ken Moffat <zarniwhoop@xxxxxxxxxxxx>
In-reply-to:
<20061231132446.10484.qmail@xxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<20061231132446.10484.qmail@xxxxxxxxxxxxxxxxxxxxxxxxx>
On Sun, Dec 31, 2006 at 06:54:46PM +0530, Arjun radhakrishna wrote: > This is the first time i'm trying an lfs build. And i've followed the book > absolutely (SVN-20061226-x86_64-Multilib) > > In chapter 10 glibc build i came across the following errors > > > malloc: using debugging hooks > make[2]: [/sources/glibc-build/posix/annexc.out] Error 1 (ignored) > make[2]: *** [/sources/glibc-build/nptl/tst-cancel1.out] Error 1 > make[1]: *** [nptl/tests] Error 2 > make: *** [check] Error 2 > > the book suggests that the first error can be ignored. > I searched on google and through the mailing lists but could not find a > solution for the tst-cancel1. > The tst-cancel1.out file is empty. > > Any help would be appreciated. > > Arjun I can't comment on that platform with glibc-2.5, but there don't seem to be many people around so I'll throw in my £0.02. I'm finishing off a desktop build on LFS svn (i686) using glibc-2.5 (against 2.6.18.x kernel headers), and on that the glibc nptl tests failed badly although the resulting desktop system seems to be ok. I guess that a change (kernel, headers, or toolchain) has proved the nptl tests are fragile. I'm also guessing that glibc-2.5 has not had a vast amount of testing yet. So, unless somebody else is building on the same platform and can say that they don't see this failure, I think you are *probably* ok to continue, As always, what really matters is how well the resulting system works. Testsuites can be useful: sometimes they highlight problems, sometimes they indicate a problem but the cause is elsewhere, sometimes they break. Sometimes, there are other errors which the testsuite doesn't notice. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce
Date: December 31, 2006
From: "Jonathan Davis" <jmdavisprog@xxxxxxxxx>
In-reply-to:
<20061231132446.10484.qmail@xxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<20061231132446.10484.qmail@xxxxxxxxxxxxxxxxxxxxxxxxx>
hi This is the first time i'm trying an lfs build. And i've followed the book absolutely (SVN-20061226-x86_64-Multilib) In chapter 10 glibc build i came across the following errors malloc: using debugging hooks make[2]: [/sources/glibc-build/posix/annexc.out] Error 1 (ignored) make[2]: *** [/sources/glibc-build/nptl/tst-cancel1.out] Error 1 make[1]: *** [nptl/tests] Error 2 make: *** [check] Error 2 the book suggests that the first error can be ignored. I searched on google and through the mailing lists but could not find a solution for the tst-cancel1. The tst-cancel1.out file is empty. Any help would be appreciated. Arjun
Well, I had the same errors for the 32-bit build for x86_64-Multilib and as far as I can tell, they haven't caused any problems. Like you, I was unable to find anything helpful online and no one ever responded to my post to CLFS-Support with a solution. However, as I said, I don't think that it's actually a big problem. In the 64-bit build I got additional errors: make[2]: *** [/usr/src/glibc/glibc-build/libio/tst-wmemstream1.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/libio/tst-wmemstream2.out] Error 1 make[2]: *** [/usr/src/glibc/glibc-build/libio/bug-wmemstream1.out] Error 1 make[1]: *** [libio/tests] Error 2 make[2]: [/usr/src/glibc/glibc-build/posix/annexc.out] Error 1 (ignored) make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancel1.out] Error 1 make[1]: *** [nptl/tests] Error 2 make: *** [check] Error 2 I assume that the wmemstream errors are related to unicode which isn't going to work on a CLFS system anyway. The other two errors are the same as the 32-bit build. In any case, I haven't had any problems from those errors. So, if you have the same errors as I do, I wouldn't worry about it too much. It'd be great if there was a way to get rid of them, but I haven't a clue how and as far as I can tell, my glibc works just fine. I'm currently working on CBLFS, so I've managed to go quite a ways on a glibc with the errors listed above. If you haven't found anything interesting online that tells you what the problem is and how to fix it, I'd suggest that you just continue with CLFS and don't worry about it. - Jonathan M Davis
Date: December 31, 2006
From: Arjun radhakrishna <arjunradhakrishna@xxxxxxxxxxx>
Arjun
_______________________________________________ Clfs-support mailing list Clfs-support@xxxxxxxxxxxxxxxxxxx http://lists.cross-lfs.org/cgi-bin/mailman/listinfo/clfs-support
Date: December 30, 2006
From: Ken Moffat <zarniwhoop@xxxxxxxxxxxx>
In-reply-to:
<200612302101.33197.sacarde@xxxxxxxxx>
References:
<200612302101.33197.sacarde@xxxxxxxxx>
On Sat, Dec 30, 2006 at 09:01:32PM +0100, sacarde wrote: > > but when I restart with clfs I have error > > > copying of device > building dt string > building dt structure > ... > ... > calling quiesce... > return from prompt init > > > and stop > Hi, again. When I replied to you yesterday on the old list, and pointed you here, you maybe did not notice that I also asked some questions, and made a suggestion. I'll summarise - Maybe your kernel .config is not appropriate. Do you know that the config you used is/was good for this machine, and are you building for powerpc, or does it perhaps say ppc in .config ? Try booting with video=ofonly to see if it helps (it sounds as if you might lose the display when it tries to switch to the framebuffer). ĸen -- das eine Mal als Tragödie, das andere Mal als Farce
Date: December 30, 2006
From: sacarde <sacarde@xxxxxxxxx>
Hi,
I try t install clfs on my mini-ppc (in hda7) , I install until "reboot
clfs" from book-SVN
I have already working system on my machine, ubuntu (in hda3)
I start ubuntu and I add lines to yaboot.conf
...
...
image=/boot/clfskernel-2.6.19.1
label=SVN-20061226
root=/dev/hda7
read-only
and run: ybin and mkofboot
but when I restart with clfs I have error
copying of device
building dt string
building dt structure
...
...
calling quiesce...
return from prompt init
and stop
can you help me ?
sacarde@xxxxxxxxxx
Date: December 30, 2006
From: "Marc Michalewicz" <grautvornix@xxxxxx>
Hello, after an extensive internet-research I still have no solution for my problem. I have built a CLFS-1.0.0 system according to the book at http://cross-lfs.org/files/BOOK/1.0.0/CLFS-1.0.0-x86.html The target is a Pentium tillamook - i tried the i586 target here, the host is an i686. Each build-step in the book went quite seamless, everything worked and I have created a Compactflash card with grub as described there (target has only CF-Slot, but it is like a HD). But during booting the target, right after the message "Freeing unused kernel memory [..]" nothing happens anymore, system hangs. In the internet I read, the configured CPU in the kernel may not the correct one - but I tried some (386, 486) without any success. The same for the whole build-process, I tried as well i486 as target, with no success either, so I am quite clueless now, and I would greatly appreciate any hint or help. Thanks in advance, Marc -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Date: December 29, 2006
From: "Jonathan Davis" <jmdavisprog@xxxxxxxxx>
Okay. I'm trying to build a multilib version of python per the CBLFS instructions. I have all of the optional packages installed. In both the 32-bit and 64-bit cases, make test fails to run very far (it can't find python's math module) and make install fails partway through. The last portion of make install's output looks like this: Listing /usr/lib/python2.5/xml/sax ... Compiling /usr/lib/python2.5/xml/sax/__init__.py ... Compiling /usr/lib/python2.5/xml/sax/_exceptions.py ... Compiling /usr/lib/python2.5/xml/sax/expatreader.py ... Compiling /usr/lib/python2.5/xml/sax/handler.py ... Compiling /usr/lib/python2.5/xml/sax/saxutils.py ... Compiling /usr/lib/python2.5/xml/sax/xmlreader.py ... Compiling /usr/lib/python2.5/xmllib.py ... Compiling /usr/lib/python2.5/xmlrpclib.py ... Compiling /usr/lib/python2.5/zipfile.py ... make: *** [libinstall] Error 1 If I run make install, then make test will work, but I don't like running make test on a partial install. Depending on how it works, it may not be a problem, but I find it undesirable. I poked around online and found a solution and a pseudo-solution. The solution only works for 64-bit and I'd prefer not to use the pseudo-solution for 32-bit if I don't have to. The solution is to change make to make EXTRA_CFLAGS="-fwrapv". For whatever reason (and the poster that posted it didn't have a clue either), that fixes the problem. Both make test and make install run just fine with that fix. As far as I can tell, that's a perfectly acceptable solution, but as I said, it only works in 64-bit. That leaves us with the pseudo-solution. If I run make -i install instead of make install, then the install is successful (for 32-bit). It of course doesn't do anything for make test since it's a change to make install. I'd much prefer to use a solution that allows the test suite to run without installing python and since the -i flag makes it so that make install simply ignores errors, I'm not convinced that it installed properly to begin with - hence why it's a "pseudo"-solution. So, if anyone here has a clue as to how to get python's make test and make install to work properly in 32-bit land, I'd definitely appreciate it. I DID try USE_ARCH=32 in case that did something, but nothing changes. While CBLFS sets up tcl to use the multiarch wrapper, it does NOT set up tk to use it. Perhaps tk should be as well and that's the problem, but I doubt it. If anyone knows, or has a suggestion, please send it my way. Thanks. - Jonathan M Davis
Date: December 24, 2006
From: Harvey Muller <hlmuller@xxxxxxxxx>
Just another way to skin a cat: Netplugd I looked at both ifplugd and netplugd. I only selected netplugd on the basis that I didn't have to install a separate daemon to use it. I haven't personally used ifplugd, so I can't compare but am pretty happy with netplugd. It was fun to figure out. What I like about it is the interface doesn't come up until I plug it in, and when I unplug it, the interface comes down. Another nice feature, is that the cable can be inserted and removed multiple times without borking dhcpcd. I'll convert my bash script to usable instructions when I get a round 'tuit,' for those that may want to give it a try.
Date: December 24, 2006
From: "Jonathan Davis" <jmdavisprog@xxxxxxxxx>
In-reply-to:
<b86643eb0612232102u27d54029m752dc53a747f79ad@xxxxxxxxxxxxxx>
References:
<b86643eb0611271831j5677386bvbda218d1be4550dd@xxxxxxxxxxxxxx> <456CC8BB.2060305@xxxxxxxxx> <b86643eb0612220633p260bf59ev7f47999562c852cf@xxxxxxxxxxxxxx> <458C7934.6020104@xxxxxxxxx> <b86643eb0612222050w14abe7d9xde2730aac3d9c646@xxxxxxxxxxxxxx> <458CB829.9020105@xxxxxxxxx> <b86643eb0612231701u7be6bff7v987a23114d7313e8@xxxxxxxxxxxxxx> <458E0574.6010003@xxxxxxxxx> <b86643eb0612232102u27d54029m752dc53a747f79ad@xxxxxxxxxxxxxx>
Well, I finally have the hotplug behavior working thanks to ifplugd. I'm going to add it to CBLFS, so hopefully that will make it easier for folks to figure it out in the future. Thanks for all your help. - Jonathan M Davis
Date: December 24, 2006
From: "Jonathan Davis" <jmdavisprog@xxxxxxxxx>
In-reply-to:
<458E0574.6010003@xxxxxxxxx>
References:
<b86643eb0611271831j5677386bvbda218d1be4550dd@xxxxxxxxxxxxxx> <456CC8BB.2060305@xxxxxxxxx> <b86643eb0612220633p260bf59ev7f47999562c852cf@xxxxxxxxxxxxxx> <458C7934.6020104@xxxxxxxxx> <b86643eb0612222050w14abe7d9xde2730aac3d9c646@xxxxxxxxxxxxxx> <458CB829.9020105@xxxxxxxxx> <b86643eb0612231701u7be6bff7v987a23114d7313e8@xxxxxxxxxxxxxx> <458E0574.6010003@xxxxxxxxx>
The difference is from talking to people is that the device udev-rules depends on the network driver being a module, it seems that udev doesn't activate the network device when it's compiled in. That explains why it doesn't work for you.
Well, that's good to know. I think that I'll use ifplugd for now, but in the future, I may set up my network driver as a module. At least now I know not to keep trying to tweak the scripts into working. Thanks for the info. - Jonathan M Davis
Date: December 24, 2006
From: Jim Gifford <clfs@xxxxxxxxx>
In-reply-to:
<b86643eb0612231701u7be6bff7v987a23114d7313e8@xxxxxxxxxxxxxx>
References:
<b86643eb0611271831j5677386bvbda218d1be4550dd@xxxxxxxxxxxxxx> <456CC8BB.2060305@xxxxxxxxx> <b86643eb0612220633p260bf59ev7f47999562c852cf@xxxxxxxxxxxxxx> <458C7934.6020104@xxxxxxxxx> <b86643eb0612222050w14abe7d9xde2730aac3d9c646@xxxxxxxxxxxxxx> <458CB829.9020105@xxxxxxxxx> <b86643eb0612231701u7be6bff7v987a23114d7313e8@xxxxxxxxxxxxxx>
Date: December 24, 2006
From: "Jonathan Davis" <jmdavisprog@xxxxxxxxx>
In-reply-to:
<458CB829.9020105@xxxxxxxxx>
References:
<b86643eb0611271831j5677386bvbda218d1be4550dd@xxxxxxxxxxxxxx> <456CC8BB.2060305@xxxxxxxxx> <b86643eb0612220633p260bf59ev7f47999562c852cf@xxxxxxxxxxxxxx> <458C7934.6020104@xxxxxxxxx> <b86643eb0612222050w14abe7d9xde2730aac3d9c646@xxxxxxxxxxxxxx> <458CB829.9020105@xxxxxxxxx>
Jonathan, the other issue could be that udev is not detecting your network adapter, I do build my as a module, so that could be the difference.
Mine certainly isn't a module and I don't really want to mess around with my kernel configuration at the moment. Updating to udev-rules 1.1-pre3 doesn't appear to have changed anything either. My guess is that the start function in the network script is being called and since there is no such function in udev-rules version, it exits with a return value of 1. I confess that I don't really understand how having only the stop function (instead of start, restart, and stop) would make the whole hotplug thing work, but on my machine it continues to be unhappy with me. The clfs-bootscripts network script works just fine (minus the hotplugability of course), but it doesn't have the desired behavior. By the way, why do the the clfs-bootscripts and udev-rules network scripts have different stop functions? The clfs-bootscripts version looks at the interfaces in sysconfig and the udev-rules version looks at the ones in /sys. As a result, the udev-rules version attempts to take down interfaces that don't even exist when the computer is shut down. I don't think that that has anything to do with my difficulties, but it strikes as me as odd that they differ in that manner. I'd guess that one was changed and the other was not updated to match. In any case, I think that I'm going to have to give up on the udev-rules network script since it isn't working and I haven't a clue how to make it work. Either my setup doesn't work with it for some reason orthere's a bug that your setup manages to avoid and mine doesn't. I think that it would be good to fix such a bug if there is one, but I haven't a clue what it could be or how to do so. In either case, thanks for your help. - Jonathan M Davis
Date: December 23, 2006
From: Jim Gifford <clfs@xxxxxxxxx>
In-reply-to:
<b86643eb0612222050w14abe7d9xde2730aac3d9c646@xxxxxxxxxxxxxx>
References:
<b86643eb0611271831j5677386bvbda218d1be4550dd@xxxxxxxxxxxxxx> <456CC8BB.2060305@xxxxxxxxx> <b86643eb0612220633p260bf59ev7f47999562c852cf@xxxxxxxxxxxxxx> <458C7934.6020104@xxxxxxxxx> <b86643eb0612222050w14abe7d9xde2730aac3d9c646@xxxxxxxxxxxxxx>
Jonathan Davis wrote:
Jonathan, the other issue could be that udev is not detecting your network adapter, I do build my as a module, so that could be the difference.Jonathan, Did you install the network support with udev-rules, (make install-network), this will load a alternative bootscript for networking, that only contains start. I do this currently without ifplugd. Just need to add both to your ethernet configuration. ONBOOT=yes # Add this to check if the adapter is available on bootupONHOTPLUG=yes # Add this to add the adapter if it called by udev/hotpluggingWell, I did use the udev-rules script, but I set ONBOOT="no", so that could be a problem, however, udev-rules' network script only has stop, not start. Now, I have udev-rules 1.1-pre2, so maybe that was fixed in 1.1-pre3. I'll go have a look. If it's the same in 1.1-pre3, then perhaps that script needs fixing. In any case, if that works, then that would definitely be nice.
Date: December 23, 2006
From: "Jonathan Davis" <jmdavisprog@xxxxxxxxx>
In-reply-to:
<458C7934.6020104@xxxxxxxxx>
References:
<b86643eb0611271831j5677386bvbda218d1be4550dd@xxxxxxxxxxxxxx> <456CC8BB.2060305@xxxxxxxxx> <b86643eb0612220633p260bf59ev7f47999562c852cf@xxxxxxxxxxxxxx> <458C7934.6020104@xxxxxxxxx>
Jonathan,
Did you install the network support with udev-rules, (make
install-network), this will load a alternative bootscript for
networking, that only contains start. I do this currently without
ifplugd. Just need to add both to your ethernet configuration.
ONBOOT=yes # Add this to check if the adapter is available on bootup
ONHOTPLUG=yes # Add this to add the adapter if it called by udev/hotplugging
Well, I did use the udev-rules script, but I set ONBOOT="no", so that could be a problem, however, udev-rules' network script only has stop, not start. Now, I have udev-rules 1.1-pre2, so maybe that was fixed in 1.1-pre3. I'll go have a look. If it's the same in 1.1-pre3, then perhaps that script needs fixing. In any case, if that works, then that would definitely be nice. - Jonathan M Davis
Date: December 23, 2006
From: Jim Gifford <clfs@xxxxxxxxx>
In-reply-to:
<b86643eb0612220633p260bf59ev7f47999562c852cf@xxxxxxxxxxxxxx>
References:
<b86643eb0611271831j5677386bvbda218d1be4550dd@xxxxxxxxxxxxxx> <456CC8BB.2060305@xxxxxxxxx> <b86643eb0612220633p260bf59ev7f47999562c852cf@xxxxxxxxxxxxxx>
Jonathan,Did you install the network support with udev-rules, (make install-network), this will load a alternative bootscript for networking, that only contains start. I do this currently without ifplugd. Just need to add both to your ethernet configuration.
ONBOOT=yes # Add this to check if the adapter is available on bootup ONHOTPLUG=yes # Add this to add the adapter if it called by udev/hotplugging
Date: December 22, 2006
From: "Jonathan Davis" <jmdavisprog@xxxxxxxxx>
In-reply-to:
<b86643eb0612220633p260bf59ev7f47999562c852cf@xxxxxxxxxxxxxx>
References:
<b86643eb0611271831j5677386bvbda218d1be4550dd@xxxxxxxxxxxxxx> <456CC8BB.2060305@xxxxxxxxx> <b86643eb0612220633p260bf59ev7f47999562c852cf@xxxxxxxxxxxxxx>
Well, I went digging around in OpenSuSE's scripts (it's my host systm) to see what they did with the dhcpcd connections and it appears that they use the ifplugd package that Joel Means mentioned. I would prefer to be able to get the ethernet behavior that I want without an extra daemon, so if someone knows how to do it by making a few adjustments to the network scripts, I'd love to know how, but for the moment, it seems that I'm going to be trying to get ifplugd to do the trick. - Jonathan Davis
Date: December 22, 2006
From: "Jonathan Davis" <jmdavisprog@xxxxxxxxx>
In-reply-to:
<456CC8BB.2060305@xxxxxxxxx>
References:
<b86643eb0611271831j5677386bvbda218d1be4550dd@xxxxxxxxxxxxxx> <456CC8BB.2060305@xxxxxxxxx>
> To get the appropriate hotplug behavior, do I need to get dhcpcd in > the background somehow, or do I need to change certain values in the > bootscripts, or do I need a separate program (such as d-bus or HAL or > something)? There's a couple of make targets in the udev rules package that aren't really well known. make install-network is one of them. I think this is what you're looking for. It modifies the existing network bootscript to only stop and starts network devices as udev finds them. ONHOTPLUG=yes needs to be present in ifconfig.[device]/[service].
Well I've obviously put off fixing this problem for quite a while considering the last post in this thread. In any case, if I use the network script from udev-rules, it always exits with an error status of 1 on boot. And on shutdown, it complains that the interfaces listedin /sys/class/net/ aren't interfaces. The second problem is probably partially due to the fact that I gave my network interface a name other than eth0, but changing it to eth0 doesn't make the first problem go away, which is the big one (I haven't checked to see whether the problem on shutdown goes away with my network interface named eth0). I tried altering the network script by replacing its stop function with the one from clfs-bootscripts, but that doesn't fix the boot problem. Unsurprisingly however, it DOES fix the problem on shutdown. My guess at the moment is that the network script is being called with "start" and since start isn't there, it exits with error code 1. I set ONHOTPLUG="yes" and ONBOOT="no", so I'm not quite sure why start would be called on the network script on boot. Perhaps if the ethernet cable were plugged in, hotplug would end up resulting in start being called, but the failure happens regardless of whether the cable is plugged in or not. I would have thought that ONBOOT="no" would have stopped that. In any case, any ideas as to what I'm missing here would be appreciated. At the moment, it just seems like the udev-rules network script doesn't work since it lacks the start function. And if the lack of start function is what allows it to use hotplug, then there's a conflict here somewhere. - Jonathan M Davis
Date: December 21, 2006
From: Ken Moffat <zarniwhoop@xxxxxxxxxxxx>
In-reply-to:
<20061220140946.GA10758@xxxxxxxxxxxxxxxxxxxxxxx>
References:
<20061220140946.GA10758@xxxxxxxxxxxxxxxxxxxxxxx>
On Wed, Dec 20, 2006 at 02:09:46PM +0000, Ken Moffat wrote:
>
> I'm guessing it might really be a _bash_ problem, but I haven't
> noticed this until now. This seems to be a pure64 x86_64/amd64
> thing, I get the same error if I run makewhatis on my pure64
> desktop, but not on my multilib systems).
>
Apologies for casting a stain on bash - it's actually a man-1.6d
problem, although I've only so far seen it on x86_64-64. There is
a missing ')' on line 263 - the relevant part of the diff from 1.6d
to 1.6e is below:
@@ -260,7 +276,7 @@
$2 ~ /^N[ÉE]V/ || $2 ~ /^NAMA/ || $2 ~ /^̾Á°/ ||
$2 ~ /^̾¾Î/ || $2 ~ /^À̸§/ || $2 ~ /^NAZWA/ ||
$2 ~ /^îáú÷áîéå/ || $2 ~ /^Ãû³Æ/ || $2 ~ /^¦WºÙ/
||
- $2 ~ /^NOME/ || $2 ~ /^NAAM/ || $2 ~ /^ÈÌÅ/) ||
+ $2 ~ /^NOME/ || $2 ~ /^NAAM/ || $2 ~ /^ÈÌÅ/)) ||
(pages == "cat" && $1 ~ /^NAME/)) {
if (!insh) {
insh = 1;
Any readers using x86_64-64 ('pure64') clfs-1.0.0 are invited to
test 'makewhatis' and edit it if they have the problem.
ĸen
--
das eine Mal als Tragödie, das andere Mal als Farce
Date: December 20, 2006
From: Ken Moffat <zarniwhoop@xxxxxxxxxxxx>
Anybody else seeing problems with makewhatis on a pure64 clfs-1.0
system ? I've finally moved my server over to clfs-1.0.0 (plus
ncursesw) and now I'm tidying up the breakages. One of these is the
nightly cron job to run makewhatis. It errors out with
awk: cmd. line:74: (pages == "cat" && $1 ~ /^NAME/)) {
awk: cmd. line:74: ^ syntax
error
awk: cmd. line:80: } else if (insh) {
awk: cmd. line:80: ^ syntax error
these messages are repeated for each pass through the loop, and
they come from lines 264 and 270 of the makewhatis shell script.
So far, I've confirmed that the errors appear to also occur if I
force the locale to C, and that the only change in this part of the
script since time immemorial is a few more additions to the variants
of $2 ~ /^NAME/ in the preceding lines.
I'm guessing it might really be a _bash_ problem, but I haven't
noticed this until now. This seems to be a pure64 x86_64/amd64
thing, I get the same error if I run makewhatis on my pure64
desktop, but not on my multilib systems).
ĸen
--
das eine Mal als Tragödie, das andere Mal als Farce
Date: December 19, 2006
From: Harvey Muller <hlmuller@xxxxxxxxx>
This is the immediate resolution, until the libtool issue gets worked
out:
Boot into the new system, and reinstall gcc. You can use the instructions
in the guide (6.6. GCC-4.1.1) with the following modifications:
1. Leave out the --build, --host, and --target configure options.
2. Leave out DESTDIR=${CLFS} from the second make command.
3. The links are already created, so you won't need to recreate them.
It is likely that you may have to rebuild other applications that use libtool.
See the companion post 'libtools - Sysroot build' in the clfs-dev mailing
list.
Best regards,
Harvey
Date: December 16, 2006
From: dperkins@xxxxxxxx
In-reply-to:
<20061215191819.GB19336@xxxxxxxxxxxxxxxxxxxxxxx>
References:
<20061215015230.65386.qmail@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <1166150878.4320.6.camel@xxxxxxxxxxxx> <20061215191819.GB19336@xxxxxxxxxxxxxxxxxxxxxxx>
> On Thu, Dec 14, 2006 at 07:47:57PM -0700, Dennis J Perkins wrote: >> This looks like something I saw last week. Using 'make >> linux-dri-x86-64' instead of 'make linux-dri' worked for me. >> >> I think this also created a /usr/X11R7/lib64 directory. > It would do, it's for multilib. I thought it still gave trouble > with savage and ffbs, maybe I'm unnecessarily stopping it from > building those. Maybe there is something else influencing my > builds, but I don't have the hardware for either of those drivers, > so I'm not concerned. > > There are a number of different files in the configs/ directory, > one per target, so plenty of scope for building it differently (e.g. > for nv on ppc I have to build 'linux' instead of 'linux-dri', I've > no idea whether that does anything useful (other than letting me run > a very slow glxgears using a lot of cpu). > > Ken > -- I noticed that it was multilib but it let me build and run X. I will probably look at it again later to see if there is a bettter solution than the one I used.
Date: December 15, 2006
From: Ken Moffat <zarniwhoop@xxxxxxxxxxxx>
In-reply-to:
<1166150878.4320.6.camel@xxxxxxxxxxxx>
References:
<20061215015230.65386.qmail@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <1166150878.4320.6.camel@xxxxxxxxxxxx>
On Thu, Dec 14, 2006 at 07:47:57PM -0700, Dennis J Perkins wrote: > This looks like something I saw last week. Using 'make > linux-dri-x86-64' instead of 'make linux-dri' worked for me. > > I think this also created a /usr/X11R7/lib64 directory. It would do, it's for multilib. I thought it still gave trouble with savage and ffbs, maybe I'm unnecessarily stopping it from building those. Maybe there is something else influencing my builds, but I don't have the hardware for either of those drivers, so I'm not concerned. There are a number of different files in the configs/ directory, one per target, so plenty of scope for building it differently (e.g. for nv on ppc I have to build 'linux' instead of 'linux-dri', I've no idea whether that does anything useful (other than letting me run a very slow glxgears using a lot of cpu). Ken -- das eine Mal als Tragödie, das andere Mal als Farce
Date: December 15, 2006
From: Ken Moffat <zarniwhoop@xxxxxxxxxxxx>
In-reply-to:
<857567.96171.qm@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<20061215135549.GA14878@xxxxxxxxxxxxxxxxxxxxxxx> <857567.96171.qm@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
On Fri, Dec 15, 2006 at 09:27:35AM -0800, Janis Stipins wrote: > > Ken Moffat <zarniwhoop@xxxxxxxxxxxx> wrote: > on x86_64 pure64 I do some extra seds before 'make linux-dri' : > sed -i -e 's/savage //' \ > -i -e 's/ ffb$//' configs/linux-dri > > Sure, that's what I ended up doing... but I'm still confused about > the message about recompiling with -fPIC. Is it just that the code > for the ffb driver uses some machine instructions that don't work > with the AMD64 processor? I was worried that maybe there was > something wrong with my GCC, because the error message didn't > seem to match the problem, somehow. > I can't answer _what_ is wrong, although I think I reached a similar conclusion. Anything to do with Mesa scares me - in my first build of X-7 everything apparently built ok, but I couldn't get anything to run, not even the background+pointer from trying to run a minimal X. [ That turned out to be missing fonts, which is why I now build all the core fonts. ] I wasted a lot of time looking at all the cannot find include file "stddef.h" messages in the Mesa build log (they are actually harmless) because no other errors showed anywhere. When I moved onto ppc64 the byzantine nature of the Mesa build really got to me. Now, I just assume it won't all build (at least in ppc, the "this hasn't been ported" messages are a bit of a giveaway) if I'm not on x86. Just taking a look at my most recent x86_64 multilib build I can see that it compiled ppc/common_ppc.c (with a warning about a missing prototype) with -DUSE_X86_64_ASM - I dread to think what horrible result that produced. Even on x86 Mesa seems to need more adjustment than anything else in X-7. As in many blfs packages, I now take the easy way out - if it seems to work, thats good enough. Ken -- das eine Mal als Tragödie, das andere Mal als Farce
Date: December 15, 2006
From: Dennis J Perkins <dperkins@xxxxxxxx>
In-reply-to:
<20061215015230.65386.qmail@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<20061215015230.65386.qmail@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
This looks like something I saw last week. Using 'make linux-dri-x86-64' instead of 'make linux-dri' worked for me. I think this also created a /usr/X11R7/lib64 directory. I moved the two files in it to /usr/X11R7/lib and created a link called lib64 that points to lib. I'm still building CLFS, but I haven't had any problems with this yet. On Thu, 2006-12-14 at 17:52 -0800, Janis Stipins wrote: > Hi, > > I've followed the CLFS-1.0.0 directions to build a pure 64-bit > xf86_64 linux installation on my AMD64 machine. So far, > everything has worked beautifully without a hitch... > > ...until I tried to build MesaLib-6.5. I have been following the > directions for Xorg7 on the CBLFS wiki... the Utility Macros, > Protocol Headers, Libraries, and libdrm all installed without > a problem. But when I try to build MesaLib-6.5, the following > error occurs: > > makedepend -fdepend -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L > -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS > -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING > -DHAVE_ALIAS -I. -I../../../../../src/mesa/drivers/dri/common -Iserver > -I../../../../../../drm/shared-core -I../../../../../include > -I../../../../../include/GL/internal -I../../../../../src/mesa > -I../../../../../src/mesa/main -I../../../../../src/mesa/glapi > -I../../../../../src/mesa/math -I../../../../../src/mesa/transform > -I../../../../../src/mesa/shader -I../../../../../src/mesa/swrast > -I../../../../../src/mesa/swrast_setup -I../../../../../src/egl/main > -I../../../../../src/egl/drivers/dri `pkg-config --cflags > libdrm` ../../common/driverfuncs.c ../common/utils.c ../common/texmem.c > ../common/vblank.c ../common/dri_util.c ../common/xmlconfig.c > ../common/drirenderbuffer.c ffb_bitmap.c ffb_clear.c ffb_dd.c ffb_depth.c > ffb_fog.c ffb_lines.c ffb_points.c ffb_span.c ffb_state.c ffb_stencil.c > ffb_tex.c ffb_tris.c ffb_vb.c ffb_xmesa.c \ > >& /dev/null > gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver > -I../../../../../../drm/shared-core -I../../../../../include > -I../../../../../include/GL/internal -I../../../../../src/mesa > -I../../../../../src/mesa/main -I../../../../../src/mesa/glapi > -I../../../../../src/mesa/math -I../../../../../src/mesa/transform > -I../../../../../src/mesa/shader -I../../../../../src/mesa/swrast > -I../../../../../src/mesa/swrast_setup -I../../../../../src/egl/main > -I../../../../../src/egl/drivers/dri `pkg-config --cflags libdrm` > -Wall -Wmissing-prototypes -g -fPIC -D_POSIX_SOURCE > -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE > -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER > -DGLX_DIRECT_RENDERING -DHAVE_ALIAS -std=c99 -ffast-math > -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE > -D_GNU_SOURCE -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER > -DGLX_DIRECT_RENDERING -DHAVE_ALIAS ffb_lines.c -o ffb_lines.o > ../../../../../bin/mklib -noprefix -o ffb_dri.so \ > ../../common/driverfuncs.o ../common/utils.o > ../common/texmem.o ../common/vblank.o ../common/dri_util.o > ../common/xmlconfig.o ../common/drirenderbuffer.o ffb_bitmap.o ffb_clear.o > ffb_dd.o ffb_depth.o ffb_fog.o ffb_lines.o ffb_points.o ffb_span.o > ffb_state.o ffb_stencil.o ffb_tex.o ffb_tris.o ffb_vb.o ffb_xmesa.o > ../../../../../src/mesa/libmesa.a -L/usr/X11R7/lib -lm -lpthread -lexpat > -ldl `pkg-config --libs libdrm` > mklib: Making Linux shared library: ffb_dri.so > /usr/bin/ld: ffb_lines.o: relocation R_X86_64_PC32 against `ffb_line' > can not be used when making a shared object; recompile with -fPIC > /usr/bin/ld: final link failed: Bad value > collect2: ld returned 1 exit status > install ffb_dri.so ../../../../../lib > install: cannot stat `ffb_dri.so': No such file or directory > make: *** [../../../../../lib/ffb_dri.so] Error 1 > > > This is strange, because it looks to me like ffb_lines.c was compiled > with the -fPIC flag. Also, the shared libraries in the other driver > subdirectories were created with no problem, so it doesn't seem > like lack of -fPIC is the real problem. > > Has anybody else had this issue? Any wisdom or suggestions would > be very much appreciated. > > Thanks, > -Janis > > > > > ______________________________________________________________________ > Have a burning question? Go to Yahoo! Answers and get answers from > real people who know. > _______________________________________________ > Clfs-support mailing list > Clfs-support@xxxxxxxxxxxxxxxxxxx > http://lists.cross-lfs.org/cgi-bin/mailman/listinfo/clfs-support
Date: December 15, 2006
From: Janis Stipins <janis_stipins@xxxxxxxxx>
In-reply-to:
<20061215135549.GA14878@xxxxxxxxxxxxxxxxxxxxxxx>
References:
<20061215135549.GA14878@xxxxxxxxxxxxxxxxxxxxxxx>
Sure, that's what I ended up doing... but I'm still confused about
on x86_64 pure64 I do some extra seds before 'make linux-dri' :
sed -i -e 's/savage //' \
-i -e 's/ ffb$//' configs/linux-dri
the second of these should stop ffb trying to build, I'm surprised
the build didn't first blow up in savage for you.
FWIW, on ppc I have to do something similar for sis.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________ Clfs-support mailing list Clfs-support@xxxxxxxxxxxxxxxxxxx http://lists.cross-lfs.org/cgi-bin/mailman/listinfo/clfs-support
Date: December 15, 2006
From: Ken Moffat <zarniwhoop@xxxxxxxxxxxx>
In-reply-to:
<20061215015230.65386.qmail@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<20061215015230.65386.qmail@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
On Thu, Dec 14, 2006 at 05:52:30PM -0800, Janis Stipins wrote:
> Hi,
>
> I've followed the CLFS-1.0.0 directions to build a pure 64-bit
> xf86_64 linux installation on my AMD64 machine. So far,
> everything has worked beautifully without a hitch...
>
> ...until I tried to build MesaLib-6.5. I have been following the
> directions for Xorg7 on the CBLFS wiki... the Utility Macros,
> Protocol Headers, Libraries, and libdrm all installed without
> a problem. But when I try to build MesaLib-6.5, the following
> error occurs:
>
> /usr/bin/ld: ffb_lines.o: relocation R_X86_64_PC32 against `ffb_line' can
> not be used when making a shared object; recompile with -fPIC
> /usr/bin/ld: final link failed: Bad value
> collect2: ld returned 1 exit status
> install ffb_dri.so ../../../../../lib
> install: cannot stat `ffb_dri.so': No such file or directory
> make: *** [../../../../../lib/ffb_dri.so] Error 1
on x86_64 pure64 I do some extra seds before 'make linux-dri' :
sed -i -e 's/savage //' \
-i -e 's/ ffb$//' configs/linux-dri
the second of these should stop ffb trying to build, I'm surprised
the build didn't first blow up in savage for you.
FWIW, on ppc I have to do something similar for sis.
ĸen
--
das eine Mal als Tragödie, das andere Mal als Farce
Date: December 15, 2006
From: Janis Stipins <janis_stipins@xxxxxxxxx>
_______________________________________________ Clfs-support mailing list Clfs-support@xxxxxxxxxxxxxxxxxxx http://lists.cross-lfs.org/cgi-bin/mailman/listinfo/clfs-support
Date: December 14, 2006
From: Harvey Muller <hlmuller@xxxxxxxxx>
This post is relative to a system built using the Sysroot - Version
SVN-0.0.1-20061211-x86 guide.
When attempting to install libusb after the base installation, the make command
fails with the following error:
/bin/sh ./libtool --mode=link g++ -g -O2 -o libusbpp.la -rpath /usr/lib
-version-info 8:4:4 -release 0.1 -export-dynamic -lusb usbpp.lo
grep: /mnt/clfs/cross-tools/i686-pc-linux-gnu/lib/libstdc++.la: No such file or
directory
/bin/sed: can't read /mnt/clfs/cross-tools/i686-pc-linux-gnu/lib/libstdc++.la:
No such file or directory
libtool: link: `/mnt/clfs/cross-tools/i686-pc-linux-gnu/lib/libstdc++.la' is
not a valid libtool archive
My initial research lead me to:
http://wiki.archlinux.org/index.php/Libtool_slaying
Further research lead me to :
http://sourceware.org/autobook/autobook/autobook_69.html#SEC69
http://www.stlinux.com/docs/getting_started-1.0/autoconf_cross_compile.php3
I also searched the libtools mailing list, but didn't find anything helpful.
Just as a general impression, it
doesn't seem the libtools developers are either sympathetic to
cross-compilation issues, or are just
unable resolve them. But that's just noise.
I am currently inclined to believe that the resolution may lie somewhere in the
second to references.
Has anyone else bumped into this and successfully resolved it? If so, could
you describe the process used?
The problem I have with the second two references above, is that they document
potential solutions using
an earlier version of libtools, which used ltconfig.
Best regards,
Harvey
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com
Date: December 13, 2006
From: Luca <liliana.perossa@xxxxxxxxxxxxx>
In-reply-to:
<45801A60.30601@xxxxxxxxxxxxx>
References:
<457FB8C4.3090909@xxxxxxxxxxxxx> <20061213140737.GA6059@xxxxxxxxxxxxxxxxxxxxxxx> <45801A60.30601@xxxxxxxxxxxxx>
Luca wrote: > Hi Ken! > > Right, it was a problem with nss headers, but I had to make an > additional patching for my Xorg-7.1 hierarchy dir (/usr/X11R7). > > Just finished installing localized Firefox-2.0 version. > > Actual supported localized versions are: cs, el, fi, fr, ga-IE, he, hu, > it, nb-NO, nl, pl, ro, sv-SE, ru. > > Luca > _______________________________________________ > Clfs-support mailing list > Clfs-support@xxxxxxxxxxxxxxxxxxx > http://lists.cross-lfs.org/cgi-bin/mailman/listinfo/clfs-support > > Just in case interested: options to add to .mozconfig file really are very clear in the first message I posted, but here again: ac_add_options --enable-ui-locale=[locale] mk_add_options MOZ_CO_LOCALES=[locales] For english there is no need to set them as it's the default. The make command should be changed to make -f client.mk checkout (needed for downloading localized sources not included in tarball) build. I just started firefox and everything use italian locale. Luca
Date: December 13, 2006
From: Luca <liliana.perossa@xxxxxxxxxxxxx>
In-reply-to:
<20061213140737.GA6059@xxxxxxxxxxxxxxxxxxxxxxx>
References:
<457FB8C4.3090909@xxxxxxxxxxxxx> <20061213140737.GA6059@xxxxxxxxxxxxxxxxxxxxxxx>
Hi Ken! Right, it was a problem with nss headers, but I had to make an additional patching for my Xorg-7.1 hierarchy dir (/usr/X11R7). Just finished installing localized Firefox-2.0 version. Actual supported localized versions are: cs, el, fi, fr, ga-IE, he, hu, it, nb-NO, nl, pl, ro, sv-SE, ru. Luca
Date: December 13, 2006
From: Ken Moffat <zarniwhoop@xxxxxxxxxxxx>
In-reply-to:
<457FB8C4.3090909@xxxxxxxxxxxxx>
References:
<457FB8C4.3090909@xxxxxxxxxxxxx>
On Wed, Dec 13, 2006 at 09:24:36AM +0100, Luca wrote: > Hello. > > I post here even if it's a CBLFS package. > > I was trying to install Firefox-2.0 32bit. > > Made some variations to ./mozconfig: > ac_add_options --prefix=/usr > ac_add_options --enable-ldap > ac_add_options --enable-pango > ac_add_options --enable-ui-locale=it > ac_add_options --with-default-mozilla-five-home=/usr/lib/firefox-2.0 > mk_add_options MOZ_CO_LOCALES=it > > so I then passed make -f client.mk checkout build as I read in a firefox > dev.l10n thread for building a localized version. > I didn't know you could do that to build locales. When problems appear, I'm suspicious what the 'checkout' is doing. > Now when it makes security/manager/ssl/src it broke with: > /usr/src/mozilla/security/manager/ssl/src/nsNSSCallbacks.h:99: error: > ‘SEC_HTTP_SERVER_SESSION’ has not been declared [...] > /usr/src/mozilla/security/manager/ssl/src/nsNSSCallbacks.h:232: error: > ‘SEC_HttpClientFcn’ does not name a type > /usr/src/mozilla/security/manager/ssl/src/nsNSSCallbacks.h: In static > member function ‘static SECStatus nsNSSHttpInterface::freeSessionFcn(int)’: > /usr/src/mozilla/security/manager/ssl/src/nsNSSCallbacks.h:173: error: > invalid static_cast from type ‘int’ to type ‘nsNSSHttpServerSession*’ [...] > I found a thread about this problem but it was in german and I don't > understand it, anyway here's the page: > http://www.sunbird-kalender.de/forum/viewtopic.php?t=888&sid=a1fc432ea790baab091db52d9b7d4c56 I'm not sure that there are any answers there. > > What's the problem? > Apparently, something is wrong in the nss headers. Are you trying to use --with-system-nss and --with-system-nspr ? For me, 2.0 builds fine on various architectures with both those options commented out. If that isn't the problem, try building it as just 'build', and then try without the pango and ldap options, to try to isolate what is triggering the problem. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce
Date: December 13, 2006
From: Luca <liliana.perossa@xxxxxxxxxxxxx>
Hello. I post here even if it's a CBLFS package. I was trying to install Firefox-2.0 32bit. Made some variations to ./mozconfig: ac_add_options --prefix=/usr ac_add_options --enable-ldap ac_add_options --enable-pango ac_add_options --enable-ui-locale=it ac_add_options --with-default-mozilla-five-home=/usr/lib/firefox-2.0 mk_add_options MOZ_CO_LOCALES=it so I then passed make -f client.mk checkout build as I read in a firefox dev.l10n thread for building a localized version. Now when it makes security/manager/ssl/src it broke with: /usr/src/mozilla/security/manager/ssl/src/nsNSSCallbacks.h:99: error: ‘SEC_HTTP_SERVER_SESSION’ has not been declared /usr/src/mozilla/security/manager/ssl/src/nsNSSCallbacks.h:105: error: ‘SEC_HTTP_SERVER_SESSION’ has not been declared /usr/src/mozilla/security/manager/ssl/src/nsNSSCallbacks.h:110: error: ‘SEC_HTTP_REQUEST_SESSION’ has not been declared /usr/src/mozilla/security/manager/ssl/src/nsNSSCallbacks.h:158: error: ‘SEC_HTTP_SERVER_SESSION’ has not been declared /usr/src/mozilla/security/manager/ssl/src/nsNSSCallbacks.h:163: error: ‘SEC_HTTP_SERVER_SESSION’ has not been declared /usr/src/mozilla/security/manager/ssl/src/nsNSSCallbacks.h:171: error: ‘SEC_HTTP_SERVER_SESSION’ has not been declared /usr/src/mozilla/security/manager/ssl/src/nsNSSCallbacks.h:177: error: ‘SEC_HTTP_SERVER_SESSION’ has not been declared /usr/src/mozilla/security/manager/ssl/src/nsNSSCallbacks.h:182: error: ‘SEC_HTTP_REQUEST_SESSION’ has not been declared /usr/src/mozilla/security/manager/ssl/src/nsNSSCallbacks.h:189: error: ‘SEC_HTTP_REQUEST_SESSION’ has not been declared /usr/src/mozilla/security/manager/ssl/src/nsNSSCallbacks.h:198: error: ‘SEC_HTTP_REQUEST_SESSION’ has not been declared /usr/src/mozilla/security/manager/ssl/src/nsNSSCallbacks.h:206: error: ‘SEC_HTTP_REQUEST_SESSION’ has not been declared /usr/src/mozilla/security/manager/ssl/src/nsNSSCallbacks.h:219: error: ‘SEC_HTTP_REQUEST_SESSION’ has not been declared /usr/src/mozilla/security/manager/ssl/src/nsNSSCallbacks.h:225: error: ‘SEC_HTTP_REQUEST_SESSION’ has not been declared /usr/src/mozilla/security/manager/ssl/src/nsNSSCallbacks.h:232: error: ‘SEC_HttpClientFcn’ does not name a type /usr/src/mozilla/security/manager/ssl/src/nsNSSCallbacks.h: In static member function ‘static SECStatus nsNSSHttpInterface::freeSessionFcn(int)’: /usr/src/mozilla/security/manager/ssl/src/nsNSSCallbacks.h:173: error: invalid static_cast from type ‘int’ to type ‘nsNSSHttpServerSession*’ /usr/src/mozilla/security/manager/ssl/src/nsNSSCallbacks.h: In static member function ‘static SECStatus nsNSSHttpInterface::setPostDataFcn(int, const char*, PRUint32, const char*)’: /usr/src/mozilla/security/manager/ssl/src/nsNSSCallbacks.h:194: error: invalid static_cast from type ‘int’ to type ‘nsNSSHttpRequestSession*’ /usr/src/mozilla/security/manager/ssl/src/nsNSSCallbacks.h: In static member function ‘static SECStatus nsNSSHttpInterface::addHeaderFcn(int, const char*, const char*)’: /usr/src/mozilla/security/manager/ssl/src/nsNSSCallbacks.h:202: error: invalid static_cast from type ‘int’ to type ‘nsNSSHttpRequestSession*’ /usr/src/mozilla/security/manager/ssl/src/nsNSSCallbacks.h: In static member function ‘static SECStatus nsNSSHttpInterface::trySendAndReceiveFcn(int, PRPollDesc**, PRUint16*, const char**, const char**, const char**, PRUint32*)’: /usr/src/mozilla/security/manager/ssl/src/nsNSSCallbacks.h:214: error: invalid static_cast from type ‘int’ to type ‘nsNSSHttpRequestSession*’ /usr/src/mozilla/security/manager/ssl/src/nsNSSCallbacks.h: In static member function ‘static SECStatus nsNSSHttpInterface::cancelFcn(int)’: /usr/src/mozilla/security/manager/ssl/src/nsNSSCallbacks.h:221: error: invalid static_cast from type ‘int’ to type ‘nsNSSHttpRequestSession*’ /usr/src/mozilla/security/manager/ssl/src/nsNSSCallbacks.h: In static member function ‘static SECStatus nsNSSHttpInterface::freeFcn(int)’: /usr/src/mozilla/security/manager/ssl/src/nsNSSCallbacks.h:227: error: invalid static_cast from type ‘int’ to type ‘nsNSSHttpRequestSession*’ make[5]: *** [nsCipherInfo.o] Error 1 make[5]: Leaving directory `/usr/src/mozilla/obj-i686-pc-linux-gnu/security/manager/ssl/src' make[4]: *** [libs] Error 2 make[4]: Leaving directory `/usr/src/mozilla/obj-i686-pc-linux-gnu/security/manager/ssl' make[3]: *** [libs] Error 2 make[3]: Leaving directory `/usr/src/mozilla/obj-i686-pc-linux-gnu/security/manager' make[2]: *** [tier_50] Error 2 make[2]: Leaving directory `/usr/src/mozilla/obj-i686-pc-linux-gnu' make[1]: *** [default] Error 2 make[1]: Leaving directory `/usr/src/mozilla/obj-i686-pc-linux-gnu' make: *** [build] Error 2 I found a thread about this problem but it was in german and I don't understand it, anyway here's the page: http://www.sunbird-kalender.de/forum/viewtopic.php?t=888&sid=a1fc432ea790baab091db52d9b7d4c56 What's the problem? Thanks in advance, Luca
Date: December 12, 2006
From: Luca <liliana.perossa@xxxxxxxxxxxxx>
Hello to all.
I've tried glibc built with gcc-4.3.0 against kernel-headers
2.6.19.{0,1} on native reiser4 file-system.
Errors with 2.6.19.1:
test-double.out
test-ildoubl.out
tst-mmap-eofsync.out
tst-mmap-fflushsync.out
tst-mktime2.out
tst-fdopendir.out
annexc.out (ignored)
tst-tls13.out
Little variations against 2.6.19:
tst-strxfrmt2.out failed
tst-fdopendir succeded
The double/ildoubl should be because of kernel-headers from what I read
in a thread.
CPU is AMD64 3300 + running as i686.
Luca
Date: December 10, 2006
From: Ken Moffat <zarniwhoop@xxxxxxxxxxxx>
FWIW, I've put a couple more hints at http://www.kenmoffat.uklinux.net/hints/ - First, an account of how I build my multilib desktops (ppc64 and x86_64) - perhaps not appropriate to everyone, and not all the same vesions as what's in cblfs, e.g. my gnome is the old stuff from blfs, but it does work. And second, a brief guide to using ncursesw with 1.0.0 (should also apply to trunk). Now, perhaps I can get back to development (if I don't get sidetracked in trying to work out how the deprecation of xkb-data should be addressed with multiple keymaps, or fixing man.conf for groff-utf8 ;-). Share and Enjoy! ĸen -- das eine Mal als Tragödie, das andere Mal als Farce
Date: December 06, 2006
From: Jim Gifford <clfs@xxxxxxxxx>
In-reply-to:
<000601c71813$1a9cd700$4501a8c0@annihilation
>
References:
<000601c71813$1a9cd700$4501a8c0@annihilation
>
Bryan Celentano wrote:
We have been making a lot of updates to the book, please tell the date of the book you used?Hello all,Not sure if I have really messed up or not. I have been following the CLFS guide to make a multilib build, I have got to the part where you can create a tarball of your install and put it on the target host. This all works well and it boots up nicely, until i reach chapters 9 and 10, I can get into linux and do most things, but I cant compile anything. I get the error "ld cannot find -lgcc" when running configure on tcl, and on some toher packages I just get the simple gcc cannot make executables. The replies to gcc -v, libc.so.6, etc are fine I think. If theres any info i need to post let me know, thank you in advance for any help.------------------------------------------------------------------------ _______________________________________________ Clfs-support mailing list Clfs-support@xxxxxxxxxxxxxxxxxxx http://lists.cross-lfs.org/cgi-bin/mailman/listinfo/clfs-support
Date: December 06, 2006
From: "Bryan Celentano" <annih@xxxxxxxxxxxxxx>
|
Hello all,
Not sure if I have really messed up or
not.
I have been following the CLFS guide to make a
multilib build, I have got to the part where you can create a tarball of your
install and put it on the target host.
This all works well and it boots up nicely, until i
reach chapters 9 and 10, I can get into linux and do most things, but I cant
compile anything.
I get the error "ld cannot find -lgcc"
when running configure on tcl, and on some toher packages I just get the simple
gcc cannot make executables.
The replies to gcc -v, libc.so.6, etc are fine I
think.
If theres any info i need to post let me know,
thank you in advance for any help.
|
_______________________________________________ Clfs-support mailing list Clfs-support@xxxxxxxxxxxxxxxxxxx http://lists.cross-lfs.org/cgi-bin/mailman/listinfo/clfs-support
Date: December 05, 2006
From: Jim Gifford <clfs@xxxxxxxxx>
In-reply-to:
<20061205142519.GA10274@xxxxxxxxxxxxxxxxxxxxxxx>
References:
<20061205142519.GA10274@xxxxxxxxxxxxxxxxxxxxxxx>
Ken Moffat wrote:
On ppc, at least for those ibooks and powerbooks where shutting the lid to go to sleep 'just works', power management is controlled by pbbuttonsd. That needs linux/radeonfb.h to compile - it was in the old linux-libc-headers and even in the kernel's own attempt at sanitised headers, but was missing from ours. I've added it to the script now, anybody with an old version of the headers can either pull a copy from the raw kernel headers or take it from http://www.kenmoffat.uklinux.net/patches/radeonfb.h ĸen
Thanx for the report Ken, I haven't tried that on my G3 Wallstreet yet.
Date: December 05, 2006
From: Jim Gifford <clfs@xxxxxxxxx>
In-reply-to:
<1165087915.4297.5.camel@xxxxxxxxxxxx>
References:
<1165087915.4297.5.camel@xxxxxxxxxxxx>
Dennis J Perkins wrote:
It is safe to ignore this issue. This test sometimes works/sometime doesn't. (Went back and checked several builds)I'm trying to run 'make check' but it keeps failing. Any suggestions? make check-TESTS make[1]: Entering directory `/source/module-init-tools-3.2.2' Building with --enable-zlib... Testing with --enable-zlib... Running tests for tests/test-depmod.Test for tests/test-depmod/01backcompat.sh failed. FAIL: tests/runtests =================== 1 of 1 tests failed =================== make[1]: *** [check-TESTS] Error 1 make[1]: Leaving directory `/source/module-init-tools-3.2.2' make: *** [check-am] Error 2 _______________________________________________ Clfs-support mailing list Clfs-support@xxxxxxxxxxxxxxxxxxx http://lists.cross-lfs.org/cgi-bin/mailman/listinfo/clfs-support
Date: December 05, 2006
From: Ken Moffat <zarniwhoop@xxxxxxxxxxxx>