Re: Avoid using libm in rootfs

In message <F1F6EC0C8B75034F9E3A79FC85122E8E71CD4A@aquib01a> you wrote:

Is it possible to avoid using libm in my roofs? Why a simple application

Yes, this is possible.

always need it? Is it needed by libc or libstdc++?

Simple applications don't need no libm. Neither  libc  nor  libstdc++
per se require libm.

It is your code and the library functions you call which causes such
dependencies. Note that you have to be aware that even innocent
looking calls like a

	printf ("Hello World\n");

may be the culprits

Example:

-> cat foo.c
#include <unistd.h>

int main (void)
{
        (void)write (1, "Hello World\n", 12);
        return 0;
}
-> export CROSS_COMPILE=ppc_6xx-
-> ppc_6xx-gcc -Wall -pedantic -o foo foo.c
-> ppc_6xx-ldd foo
        libc.so.6 => /opt/eldk/ppc_6xx/lib/libc.so.6
        ld.so.1 => /opt/eldk/ppc_6xx/lib/ld.so.1

You see: no libm needed.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Too much of anything, even love, isn't necessarily a good thing.
	-- Kirk, "The Trouble with Tribbles", stardate 4525.6

Hi,

Maybe on the same subject or OT, I'm having trouble with ELDK 4.1.0, kernel=
=20
2.4.25, u-boot 1.1.6, kernel and ramdisk copied from flash into RAM on a=20
TQM860L module.

Using a fresh ramdisk and installed busybox 1.4.2, plus the shared libs fro=
m=20
ELDK, init barks that it can not find /lib/libc.so.6, although it's there=20
(case 1)

Using fresh ELDK ramdisk, init complains about missing libm.so.6, although =
it=20
is there... (case 2)

Some ldd and readelf output:

case 1:
devel01:/devel/abts_devel/work/tom/tq_ramdisk # ppc_8xx-ldd=20
tmp_mount/bin/busybox
        libcrypt.so.1=20
=3D> /devel.rtl01/bist_devel/tools/ppc/eldk-4.1.0/ppc_8xx/lib/libcrypt.so.1
        libc.so.6=20
=3D> /devel.rtl01/bist_devel/tools/ppc/eldk-4.1.0/ppc_8xx/lib/libc.so.6
        ld.so.1=20
=3D> /devel.rtl01/bist_devel/tools/ppc/eldk-4.1.0/ppc_8xx/lib/ld.so.1

devel01:/devel/abts_devel/work/tom/tq_ramdisk # ppc_8xx-readelf -d=20
tmp_mount/bin/busybox | grep NEEDED
 0x00000001 (NEEDED)                     Shared library: [libcrypt.so.1]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]

case 2:
devel01:/devel/abts_devel/work/tom/tq_ramdisk # ppc_8xx-ldd new/bin/busybox
        libcrypt.so.1=20
=3D> /devel.rtl01/bist_devel/tools/ppc/eldk-4.1.0/ppc_8xx/lib/libcrypt.so.1
        libm.so.6=20
=3D> /devel.rtl01/bist_devel/tools/ppc/eldk-4.1.0/ppc_8xx/lib/libm.so.6
        libc.so.6=20
=3D> /devel.rtl01/bist_devel/tools/ppc/eldk-4.1.0/ppc_8xx/lib/libc.so.6
        ld.so.1=20
=3D> /devel.rtl01/bist_devel/tools/ppc/eldk-4.1.0/ppc_8xx/lib/ld.so.1

devel01:/devel/abts_devel/work/tom/tq_ramdisk # ppc_8xx-readelf -d=20
new/bin/busybox |grep NEEDED
 0x00000001 (NEEDED)                     Shared library: [libcrypt.so.1]
 0x00000001 (NEEDED)                     Shared library: [libm.so.6]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]

Shouldn't the paths from ldd be for example /lib/libc.so.6 ?

Anybody has any idea what that could be?
I'll gladly provide any other information you'll need.

Thanks much in advance
Tom

On Thursday 29 March 2007 12:29, Wolfgang Denk wrote:

In message <F1F6EC0C8B75034F9E3A79FC85122E8E71CD4A@aquib01a> you wrote:

quoted

Is it possible to avoid using libm in my roofs? Why a simple application

Yes, this is possible.

quoted

always need it? Is it needed by libc or libstdc++?

Simple applications don't need no libm. Neither  libc  nor  libstdc++
per se require libm.

It is your code and the library functions you call which causes such
dependencies. Note that you have to be aware that even innocent
looking calls like a

	printf ("Hello World\n");

may be the culprits

=2D-=20
Thomas Maenner
Engineering Project Manager
AEHR Test Systems
400 Kato Terrace
=46remont, CA 94539
Phone: =A0+1-510-623-9400x323
Cell: =A0 +1-925-389-6653
=46ax: =A0 =A0+1-510-623-9450
E-Mail: mailto:tmaenner@aehr.com

I have 2 targets, both kernel.org linux-2.6.17.11. Both are currently =
using rootfile systems from montavista's 2.6.10 distribution. One is a =
PPC8241 and the other is a PPC8541.
=20
On the 8241, I can login with a telnet session as root. On the 8541, I =
cannot. On both, I can login at the serial terminal as root with no =
passwd.
=20
Neither as a password for root in /etc/passwd. That is, the first line =
in the passwd file says "root::0:0:root:/root/bin/bash".
=20
Being toasters, I dont want a password to cook my toast.
=20
The question is:
=20
"What are the various things that might cause one toaster to be able to =
login from a telnet session and another, very similar one to not be able =
to do this?"
=20
Charles
=20

=20
________________________________

From: Bill Gatliff [mailto:bgat@billgatliff.com]
Sent: Fri 3/30/2007 8:53 PM
To: Charles Krinke
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: PPC login puzzle



Charles:

Charles Krinke wrote:

I have 2 targets, both kernel.org linux-2.6.17.11. Both are currently =

using rootfile systems from montavista's 2.6.10 distribution. One is a =
PPC8241 and the other is a PPC8541.

=20
On the 8241, I can login with a telnet session as root. On the 8541, I =

cannot. On both, I can login at the serial terminal as root with no =
passwd.

=20
Neither as a password for root in /etc/passwd. That is, the first line =

in the passwd file says "root::0:0:root:/root/bin/bash".

=20
Being toasters, I dont want a password to cook my toast.
=20
The question is:
=20
"What are the various things that might cause one toaster to be able =

to login from a telnet session and another, very similar one to not be =
able to do this?"

=20

Are their /etc/securetty files identical?


b.g.

--
Bill Gatliff
bgat@billgatliff.com <mailto:bgat@billgatliff.com>=20


Yes, that that is another part of the puzzle as both the /etc/securetty =
and the /etc/xinetd.d/telnet files are identical in both root =
filesystems. So, there must be some ither file somewhere keeping me from =
cooking my toast with a telnet login to the 8541.
=20
Charles

Charles:

Charles Krinke wrote:

I have 2 targets, both kernel.org linux-2.6.17.11. Both are currently using rootfile systems from montavista's 2.6.10 distribution. One is a PPC8241 and the other is a PPC8541.
 
On the 8241, I can login with a telnet session as root. On the 8541, I cannot. On both, I can login at the serial terminal as root with no passwd.
 
Neither as a password for root in /etc/passwd. That is, the first line in the passwd file says "root::0:0:root:/root/bin/bash".
 
Being toasters, I dont want a password to cook my toast.
 
The question is:
 
"What are the various things that might cause one toaster to be able to login from a telnet session and another, very similar one to not be able to do this?"
  

Are their /etc/securetty files identical?


b.g.

-- 
Bill Gatliff
bgat@billgatliff.com

<snip...>

Yes, that that is another part of the puzzle as both the /etc/securetty
and the /etc/xinetd.d/telnet files are identical in both root filesystems.
So, there must be some ither file somewhere keeping me from cooking my toast
with a telnet login to the 8541.

Seems to me thing you can do is find out why the telnet session is being
rejected.  Have you done an ethernet capture?

Do you have any firewalling setup?  In that case you need to make sure your
rules are setup properly.  The ethernet capture should give you a clue.

Are you sure the telnetd can be found on your system that doesn't work?
What do the logs tell you on the machine that doesn't work?  I think xinetd
kicks out a log file, what does that tell you?

Have you tried on the 8541,  login to the terminal and then telnet to
localhost?  If you can do that, then I'd say it's a firewalling problem, if
not, then it's a telnetd type of problem.


Hope that helps.

-stv

-- 
/*
* Steve Iribarne
* Software Engineer
* (aka Grunt)
*/

Seems to me thing you can do is find out why the telnet session is being =
rejected.  Have you done an ethernet capture?=20

Do you have any firewalling setup?  In that case you need to make sure =
your rules are setup properly.  The ethernet capture should give you a =
clue.=20

Are you sure the telnetd can be found on your system that doesn't work?  =
What do the logs tell you on the machine that doesn't work?  I think =
xinetd kicks out a log file, what does that tell you?

Have you tried on the 8541,  login to the terminal and then telnet to =
localhost?  If you can do that, then I'd say it's a firewalling problem, =
if not, then it's a telnetd type of problem. =20


Hope that helps.
-stv
--=20
/*
* Steve Iribarne
* Software Engineer
* (aka Grunt)=20
*/
=20
It is interesting that 'telnet localhost' fails in a similar way as =
telnet across the network, and I appreciate your kind hints, especially =
about the log file and /var/log/syslog helps a bit on this problem.
=20
When trying to telnet accross the network, syslog says
=20
in.telnetd[]: connect from x.x.x.x
=20
But entering root doesnt work and the host then says:
sff1 login: root
Login incorrect
=20
There are no further errors on the 8541. When trying to 'telnet =
localhost', syslog says
=20
in.telnetd[]: connect from 127.0.0.1
=20
But neither completes the login, so although there is a clue here, the =
logical path to conclusion is still escaping me a little bit.
=20
I can see that both targets have the same /etc/xinted.d/telnet file and =
it contains:
=20
service telnet
{
 flags  =3D REUSE
 socket_type =3D stream       =20
 protocol =3D tcp
 wait  =3D no
 user  =3D root
 server  =3D /usr/sbin/in.telnetd
 server_args =3D -h
 log_on_failure +=3D USERID
}
=20
which I think is reasonable in this situation. So, this begs the =
question of what other things still bear on this type of problem. Again, =
I appreciate your taking the time to help me understand a bit more of =
how this fits together.
=20
Charles
=20
=20

Charles Krinke wrote:

Seems to me thing you can do is find out why the telnet session is being rejected.  Have you done an ethernet capture? 

Do you have any firewalling setup?  In that case you need to make sure your rules are setup properly.  The ethernet capture should give you a clue. 

Are you sure the telnetd can be found on your system that doesn't work?  What do the logs tell you on the machine that doesn't work?  I think xinetd kicks out a log file, what does that tell you?

Have you tried on the 8541,  login to the terminal and then telnet to localhost?  If you can do that, then I'd say it's a firewalling problem, if not, then it's a telnetd type of problem.  
  

Isn't there a config file that tells telnetd whether a root login is ok?


b.g.

-- 
Bill Gatliff
bgat@billgatliff.com

On 3/31/07, Charles Krinke [off-list ref] wrote:

Seems to me thing you can do is find out why the telnet session is being
rejected.  Have you done an ethernet capture?

<snip....>
It is interesting that 'telnet localhost' fails in a similar way as telnet
across the

Ok.. This tells me it's a telnet problem.  So either the telentd isn't
starting up properly on this system OR there is some weird rights thing that
you have setup differently on both systems.

Are you using anything like busybox?  Which telnet are you using.  It's
killing me because I know I have run into this same problem.  But I am old
and I forgot what I did.  I had this problem about 3 years ago.. ugh.

To me it was something with securetty or the like.  There is a config file
that allows telnet or not.  Another thing to try is to load telnetd with
more options.  I think there is "-a debug" you can turn on and that will
turn on the authentication debugging... "-D report" should also help you
out.

I'm sure it has something to do with root not being able to logon or maybe
it's the blank password.  Create a password for root and see if that helps.

-stv


network, and I appreciate your kind hints, especially about the log file and

/var/log/syslog helps a bit on this problem.

When trying to telnet accross the network, syslog says

in.telnetd[]: connect from x.x.x.x

But entering root doesnt work and the host then says:
sff1 login: root
Login incorrect

There are no further errors on the 8541. When trying to 'telnet
localhost', syslog says

in.telnetd[]: connect from 127.0.0.1

But neither completes the login, so although there is a clue here, the
logical path to conclusion is still escaping me a little bit.

I can see that both targets have the same /etc/xinted.d/telnet file and it
contains:

service telnet
{
flags  = REUSE
socket_type = stream
protocol = tcp
wait  = no
user  = root
server  = /usr/sbin/in.telnetd
server_args = -h
log_on_failure += USERID
}

which I think is reasonable in this situation. So, this begs the question
of what other things still bear on this type of problem. Again, I appreciate
your taking the time to help me understand a bit more of how this fits
together.

Charles

-- 
/*
* Steve Iribarne
* Software Engineer
* (aka Grunt)
*/

Are you using anything like busybox?  Which telnet are you using.  It's
killing me because I know I have run into this same problem.  But I am old
and I forgot what I did.  I had this problem about 3 years ago.. ugh.

To me it was something with securetty or the like.  There is a config file
that allows telnet or not.  Another thing to try is to load telnetd with
more options.  I think there is "-a debug" you can turn on and that will
turn on the authentication debugging... "-D report" should also help you
out.

I had a problem like this with telnet on an older linux with busybox and 
tiny login...

my problem had to do with making sure I had /dev/ptyX created...

so I just did:

cd /dev
MAKEDEV pty

not sure if that's your problem, but it's just something else to look into..

-Eric

_________________________________________________________________
Live Search Maps � find all the local information you need, right when you 
need it. http://maps.live.com/?icid=hmtag2&FORM=MGAC01