Re: [lfs-dev] glibc '::gets' breakage
Andrew Benton wrote: > But according to that bugzilla page, the bug was fixed weeks ago? The > 'fix' is definitely in the glibc source so it would appear that it's > not working. I assume that by this you mean you've verified that the right-hand side of this diff is present in your git tree? http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=8ecd6b2a1283a28bcf56cfe48099fafa412a3929 That *seems* like it should fix the issue. What does the installed stdio.h look like? What happens if you do something like "/path/g++ -E -D_GNU_SOURCE -Wp,-dU /usr/include/stdio.h"? (Assuming that's where the stdio.h from this glibc build got installed, anyway.) Do you get __USE_ISOC11 #define'd (to what value?) or #undef'ed? What about __cplusplus (again, what value)? signature.asc Description: OpenPGP digital signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] lfs bootscripts and multiple instances
de...@hawaii.rr.com wrote:
> Bruce Dubbs wrote:
>>> BTW: statusproc() defined in /lib/lsb/init-functions has an "exit 1" just
>>> after
>>> it prints its Usage statement; shouldn't this be a "return 1" instead?
>> statusproc is a function to print out a nicely formatted status message
>>from the results of pidofproc. It was designed to be used in an
>> initialization script as in './script status' If you give it the wrong
>> parameters, then that script should start. If you want to use the info
>> and do error handling, use pidofproc instead.
>
> If that's how it's meant to be used (I presume you meant "script should
> stop") then that makes sense.
Yes, I did mean stop.
> It's an oddball function though - the
> only one in /lib/lsb/init-functions that prints a usage statement and
> the only one that exits instead of returning an error code - which led
> to the confusing (to me anyway) situation where using it on the command
> line with incorrect/missing options prints a usage statement followed
> immediately by terminating your login shell.
It's a convenience function for the boot scripts. Always been that way
AFAIK.
>> statusproc just uses what is returned from pidofproc. Since you are
>
> Aha! After the argument processing loop in statusproc(), the logic in the
> test for the pidfile name is backward; the pidfile argument to statusproc
> never gets passed on to pidofproc():
>
> (lfs-bootscripts-20120116/lfs/lib/services/init-functions line 513-517)
>
> if [ -z "${pidfile}" ]; then
>pidlist=`pidofproc -p "${pidfile}" $@`
> else
>pidlist=`pidofproc $@`
> fi
OK, change -z to -n
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] lfs bootscripts and multiple instances
Bruce Dubbs wrote:
>> BTW: statusproc() defined in /lib/lsb/init-functions has an "exit 1" just
>> after
>> it prints its Usage statement; shouldn't this be a "return 1" instead?
>
>statusproc is a function to print out a nicely formatted status message
>from the results of pidofproc. It was designed to be used in an
>initialization script as in './script status' If you give it the wrong
>parameters, then that script should start. If you want to use the info
>and do error handling, use pidofproc instead.
If that's how it's meant to be used (I presume you meant "script should
stop") then that makes sense. It's an oddball function though - the
only one in /lib/lsb/init-functions that prints a usage statement and
the only one that exits instead of returning an error code - which led
to the confusing (to me anyway) situation where using it on the command
line with incorrect/missing options prints a usage statement followed
immediately by terminating your login shell.
>statusproc just uses what is returned from pidofproc. Since you are
Aha! After the argument processing loop in statusproc(), the logic in the
test for the pidfile name is backward; the pidfile argument to statusproc
never gets passed on to pidofproc():
(lfs-bootscripts-20120116/lfs/lib/services/init-functions line 513-517)
if [ -z "${pidfile}" ]; then
pidlist=`pidofproc -p "${pidfile}" $@`
else
pidlist=`pidofproc $@`
fi
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] zlib 1.2.6 incompatibilities
- Original Message - From: "Tobias Gasser" To: Sent: Friday, February 03, 2012 7:27 AM Subject: [lfs-dev] zlib 1.2.6 incompatibilities > > zlib 1.2.6 seems to have some issues. > > building partimage 0.6.9 fails with several errors in imagefile.cpp > > error cannot convert 'gzFile_s**' to 'gzFile' for argument... > > using zlib 1.2.5 fixes this error. > > google was no help, possibly i'm the first to hit this issue as zlib > 1.2.6 was released just some days ago. > > maybe there are other packages having problems with the new zlib. > partimage is one of the first packages i build after lfs as it does not > require any X-stuff. > You should report your issue. If I understand well this message http://mail.madler.net/pipermail/zlib-devel_madler.net/2012-January/002731.html 1.2.7 may not be far away. I found 2 new warnings in module-init-tools-3.16 ... gcc -DPACKAGE_NAME=\"module-init-tools\" -DPACKAGE_TARNAME=\"module-init-too ls\" -DPACKAGE_VERSION=\"3.16\" -DPACKAGE_STRING=\"module-init-tools\ 3.16\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"module-init-t ools\" -DVERSION=\"3.16\" -DCONFIG_USE_ZLIB=1 -I. -I.. -Os -march=i486 - mtune=pentium -pipe -fomit-frame-pointer -Wunused -Wall -MT zlibsupport.o -MD -MP -MF .deps/zlibsupport.Tpo -c -o zlibsupport.o ../zlibsupport.c ../zlibsupport.c: In function 'grab_contents': ../zlibsupport.c:30: warning: passing argument 1 of 'gzread' from incompatible pointer type /usr/include/zlib.h:1290: note: expected 'gzFile' but argument is of type 'struct gzFile_s **' ../zlibsupport.c: In function 'grab_file': ../zlibsupport.c:56: warning: passing argument 1 of 'grab_contents' from incompatible pointer type ../zlibsupport.c:23: note: expected 'struct gzFile_s **' but argument is of type 'gzFile' I found only that when diffing my entire log build. Gilles -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] lfs bootscripts and multiple instances
Dean Takemori wrote:
> I'm trying to setup multiple instances of rsyslog (one for kernel
> messages) using lfs-bootscripts-20120116 and running into some
> problems.
>
> I'm using rsyslogd 5.8.6, which is designed with multiple instance
> support. I've set up one configuration file (/etc/rsysklog.conf)
> for the kernel logger and one for the system logger (/etc/rsyslog.conf)
>
> rsyslogd's
> -i flag specifies the pid file used and
> -f specifies the configuration file.
>
>> root:~# source /lib/lsb/init-functions
>>
>> root:~# start_daemon -p /run/rsyslogd.pid /sbin/rsyslogd -i
>> /run/rsyslogd.pid -f /etc/rsyslog.conf
>> root:~# echo $?
>> 0
>
> Now let's check:
>
>> root:~# ps xa | grep rsyslogd
>> 8045 ?Sl 0:00 /sbin/rsyslogd -i /run/rsyslogd/pid -f
>> /etc/rsyslog.conf
>> 8131 tty1 s+ 0:00 grep rsyslog
>>
>> root:~# stausproc -p /run/rsyslogd.pid /rsbin/rsyslogd
>> rsyslogd is running with Process ID(s) 8045
>>
>> root:# cat /run/rsyslogd.pid
>> 8045
>
> So far so good.
>
> But now let's try running the second instance.
>
>> root:~# start_daemon -p /run/rsysklogd.pid /sbin/rsyslogd -i
>> /run/rsysklogd.pid -f /etc/rsysklog.conf
>> root:~# echo $?
>> 0
>
> and now check:
>> root:~# ps xa | grep rsyslogd
>> 8045 ?Sl 0:00 /sbin/rsyslogd -i /run/rsyslogd.pid -f
>> /etc/rsyslog.conf
>> 8133 tty1 s+ 0:00 grep rsyslog
>
>
> What?
>
> Note that rsyslog behaves as expected:
>
>> root:~# sbin/rsyslogd -i /run/rsysklogd.pid -f /etc/rsysklog.conf
>> root:~# echo $?
>> 0
>>
>> root:~# ps xa | grep rsyslogd
>> 8045 ?Sl 0:00 /sbin/rsyslogd -i /run/rsyslogd.pid -f
>> /etc/rsyslog.conf
>> 8149 ?Sl 0:00 /sbin/rsyslogd -i /run/rsysklogd.pid -f
>> /etc/rsysklog.conf
>> 8155 tty1 s+ 0:00 grep rsyslog
>>
>> root:~# cat /run/rsyslogd.pid
>> 8045
>> root:~# cat /run/rsysklogd.pid
>> 8149
>
>
> So far, I think I've tracked the problem down to statusproc() not correctly
> using the pidfile it's given.
>
> Namely: this is correct
>
>> root:~# statusproc -p /run/rsyslogd.pid /sbin/rsyslogd
>> rsyslogd is running with Process ID(s) 8045
>>
>> root:~# cat /run/rsyslogd.pid
>> 8045
>
> But this is not
>> root:~# statusproc -p /run/rsysklogd.pid /sbin/rsyslogd
>> rsyslogd is running with Process ID(s) 8045
>>
>> root:~# cat /run/rsysklogd.pid
>> 8149
statusproc just uses what is returned from pidofproc. Since you are
specifying a pidfile, pidofproc is doing:
pidlist=`/bin/head -n1 "${pidfile}"`
It then checks to see if the pids in pidlist are running.
In line 460, we have:
lpids="${pids}${pid} "
but pids is never defined. Try changing that line to
lpids="${lpids}${pid} "
and see if that makes a difference. If that doesn't help, throw in a
few echo or cat statements at the right places to see what it going on.
If you identify another problem, we'll certainly address it.
> BTW: statusproc() defined in /lib/lsb/init-functions has an "exit 1" just
> after
> it prints its Usage statement; shouldn't this be a "return 1" instead?
statusproc is a function to print out a nicely formatted status message
from the results of pidofproc. It was designed to be used in an
initialization script as in './script status' If you give it the wrong
parameters, then that script should start. If you want to use the info
and do error handling, use pidofproc instead.
> BTW2: statusproc()'s Usage statement says :
> echo "Usage: [-p pidfile] statusproc {program}"
> Shouldn't this be this?
> echo "Usage: statusproc [-p pidfile] {program}"
I've fixed this in my sandbox. It will be updated at the next commit.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] lfs bootscripts and multiple instances
On 02/03/2012 01:55 AM, Dean Takemori wrote:
> I'm trying to setup multiple instances of rsyslog (one for kernel
> messages) using lfs-bootscripts-20120116 and running into some
> problems.
>
> I'm using rsyslogd 5.8.6, which is designed with multiple instance
> support. I've set up one configuration file (/etc/rsysklog.conf)
> for the kernel logger and one for the system logger (/etc/rsyslog.conf)
>
> rsyslogd's
> -i flag specifies the pid file used and
> -f specifies the configuration file.
>
>> root:~# source /lib/lsb/init-functions
>>
>> root:~# start_daemon -p /run/rsyslogd.pid /sbin/rsyslogd -i
>> /run/rsyslogd.pid -f /etc/rsyslog.conf
>> root:~# echo $?
>> 0
> Now let's check:
>
>> root:~# ps xa | grep rsyslogd
>> 8045 ?Sl 0:00 /sbin/rsyslogd -i /run/rsyslogd/pid -f
>> /etc/rsyslog.conf
>> 8131 tty1 s+ 0:00 grep rsyslog
>>
>> root:~# stausproc -p /run/rsyslogd.pid /rsbin/rsyslogd
>> rsyslogd is running with Process ID(s) 8045
>>
>> root:# cat /run/rsyslogd.pid
>> 8045
> So far so good.
>
> But now let's try running the second instance.
>
>> root:~# start_daemon -p /run/rsysklogd.pid /sbin/rsyslogd -i
>> /run/rsysklogd.pid -f /etc/rsysklog.conf
>> root:~# echo $?
>> 0
> and now check:
>> root:~# ps xa | grep rsyslogd
>> 8045 ?Sl 0:00 /sbin/rsyslogd -i /run/rsyslogd.pid -f
>> /etc/rsyslog.conf
>> 8133 tty1 s+ 0:00 grep rsyslog
>
> What?
>
> Note that rsyslog behaves as expected:
>
>> root:~# sbin/rsyslogd -i /run/rsysklogd.pid -f /etc/rsysklog.conf
>> root:~# echo $?
>> 0
>>
>> root:~# ps xa | grep rsyslogd
>> 8045 ?Sl 0:00 /sbin/rsyslogd -i /run/rsyslogd.pid -f
>> /etc/rsyslog.conf
>> 8149 ?Sl 0:00 /sbin/rsyslogd -i /run/rsysklogd.pid -f
>> /etc/rsysklog.conf
>> 8155 tty1 s+ 0:00 grep rsyslog
>>
>> root:~# cat /run/rsyslogd.pid
>> 8045
>> root:~# cat /run/rsysklogd.pid
>> 8149
>
> So far, I think I've tracked the problem down to statusproc() not correctly
> using the pidfile it's given.
>
> Namely: this is correct
>
>> root:~# statusproc -p /run/rsyslogd.pid /sbin/rsyslogd
>> rsyslogd is running with Process ID(s) 8045
>>
>> root:~# cat /run/rsyslogd.pid
>> 8045
> But this is not
>> root:~# statusproc -p /run/rsysklogd.pid /sbin/rsyslogd
>> rsyslogd is running with Process ID(s) 8045
>>
>> root:~# cat /run/rsysklogd.pid
>> 8149
>
>
>
> BTW: statusproc() defined in /lib/lsb/init-functions has an "exit 1" just
> after
> it prints its Usage statement; shouldn't this be a "return 1" instead?
>
> BTW2: statusproc()'s Usage statement says :
> echo "Usage: [-p pidfile] statusproc {program}"
> Shouldn't this be this?
> echo "Usage: statusproc [-p pidfile] {program}"
Yes, statusproc() looks broken. Might it be better to use pidofproc()
directly where possible? Not sure that statusproc() should be needed any
longer. I haven't had the time to dig too deep into the wrapper
functions since the rewrite. I'll have a look at them later today, but
hopefully Bruce can chime in here today as well. Not sure about the exit
vs return.
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
[lfs-dev] glibc '::gets' breakage
Hello, I've tried to build LFS with current glibc from git (well, current as of yesterday) and the second pass of gcc (the first one after installing glibc into /tools) failed like this: Making all in libsupc++ make[4]: Entering directory `/mnt/lfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++' /bin/sh ../libtool --tag CXX --tag disable-shared --mode=compile /mnt/lfs/sources/gcc-build/./gcc/xgcc -shared-libgcc -B/mnt/lfs/sources/gcc-build/./gcc -nostdinc++ -L/mnt/lfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/mnt/lfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/tools/x86_64-unknown-linux-gnu/bin/ -B/tools/x86_64-unknown-linux-gnu/lib/ -isystem /tools/x86_64-unknown-linux-gnu/include -isystem /tools/x86_64-unknown-linux-gnu/sys-include -I/mnt/lfs/sources/gcc-4.6.2/libstdc++-v3/../gcc -I/mnt/lfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/mnt/lfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/mnt/lfs/sources/gcc-4.6.2/libstdc++-v3/libsupc++ -fno-implicit-templates -prefer-pic -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -c -o vterminate.lo ../../../../gcc-4.6.2/li bstdc++-v3/libsupc++/vterminate.cc libtool: compile: /mnt/lfs/sources/gcc-build/./gcc/xgcc -shared-libgcc -B/mnt/lfs/sources/gcc-build/./gcc -nostdinc++ -L/mnt/lfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/mnt/lfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/tools/x86_64-unknown-linux-gnu/bin/ -B/tools/x86_64-unknown-linux-gnu/lib/ -isystem /tools/x86_64-unknown-linux-gnu/include -isystem /tools/x86_64-unknown-linux-gnu/sys-include -I/mnt/lfs/sources/gcc-4.6.2/libstdc++-v3/../gcc -I/mnt/lfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/mnt/lfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/mnt/lfs/sources/gcc-4.6.2/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -c ../../../../gcc-4.6.2/libstdc++-v3/libsupc++/vterminate.cc -fPIC -DPIC -o vterminate.o In file included from ../../../../gcc-4.6.2/libstdc++-v3/libsupc++/vterminate.cc:32:0: /mnt/lfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/cstdio:118:11: error: '::gets' has not been declared make[4]: *** [vterminate.lo] Error 1 make[4]: Leaving directory `/mnt/lfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/mnt/lfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3' make[2]: *** [all] Error 2 make[2]: Leaving directory `/mnt/lfs/sources/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3' make[1]: *** [all-target-libstdc++-v3] Error 2 make[1]: Leaving directory `/mnt/lfs/sources/gcc-build' make: *** [all] Error 2 andy@eccles:/mnt/lfs/sources/gcc-build$ Googling on the error led me to this: http://gcc.gnu.org/ml/gcc/2012-01/msg00041.html and this: http://sourceware.org/bugzilla/show_bug.cgi?id=13566 But according to that bugzilla page, the bug was fixed weeks ago? The 'fix' is definitely in the glibc source so it would appear that it's not working. Could someone who knows what they're doing have a look at this please? Andy -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Latest Changes
Le 03/02/2012 06:04, Bryan Kadzban a écrit :
> But this is it:
>
>> # ignore KVM virtual interfaces
>> ENV{MATCHADDR}=="52:54:00:*", GOTO="persistent_net_generator_end"
>
> (From /lib/udev/rules.d/75-persistent-net-generator.rules.)
It might not work on real hardware machines under Fedora 16:
Because they have switched to the "biosdevname" naming scheme
of interfaces, the device name is p2p1 instead of eth0, and that prevents
the rule to be generated as well:
# device name whitelist
KERNEL!="eth*|ath*|wlan*[0-9]|msh*|ra*|sta*|ctc*|lcs*|hsi*", \
GOTO="persistent_net_generator_end"
Actually, this makes sense since biosdevname allows to have a consistent
naming scheme. But jhalfs bombs out as said by Bruce.
Regards
Pierre
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
