Avoid using libm in rootfs

Avoid using libm in rootfs

[DI BACCO ANTONIO - technolabs]

[-- Attachment #1: Type: text/plain, Size: 148 bytes --]

Is it possible to avoid using libm in my roofs? Why a simple application
always need it? Is it needed by libc or libstdc++?
 
Bye,
Antonio.
 

[-- Attachment #2: Type: text/html, Size: 761 bytes --]

Re: Avoid using libm in rootfs

[Wolfgang Denk]

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

Re: Avoid using libm in rootfs

[Thomas Maenner]

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:
> > 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

=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

Re: Avoid using libm in rootfs

[Wolfgang Denk]

In message <200703291345.35978.tmaenner@aehr.com> you wrote:
> 
> Maybe on the same subject or OT, I'm having trouble with ELDK 4.1.0, kernel
> 2.4.25, u-boot 1.1.6, kernel and ramdisk copied from flash into RAM on a 
> TQM860L module.

Using ELDK 4.1 (= a toolchain build for a  2.6  kernel)  with  a  2.4
kernel  is  not  a supported mode of operation. Please use ELDK 3.1.1
for runtime environment of your 2.4 kernel.

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

No, the cross-version of ldd shows the full path name in the cross
environment.

> Anybody has any idea what that could be?

Incompatibility of libraries. Use ELDK 3.x with 2.4 kernels, and ELDK
4.x with 2.6 kernels; anything else is asking for trouble.

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
God is real, unless declared integer.

Re: Avoid using libm in rootfs

[Thomas Maenner]

Thanks Wolfgang, I saw the trouble ;)

Just for the rest, who might be struggling here:
Switched back to ELDK 3.1.1, kernel 2.4.25, busybox 1.4.2 and things worked 
fine again.

Thanks much!
Tom

On Thursday 29 March 2007 14:27, Wolfgang Denk wrote:
> In message <200703291345.35978.tmaenner@aehr.com> you wrote:
> > Maybe on the same subject or OT, I'm having trouble with ELDK 4.1.0,
> > kernel 2.4.25, u-boot 1.1.6, kernel and ramdisk copied from flash into
> > RAM on a TQM860L module.
>
> Using ELDK 4.1 (= a toolchain build for a  2.6  kernel)  with  a  2.4
> kernel  is  not  a supported mode of operation. Please use ELDK 3.1.1
> for runtime environment of your 2.4 kernel.
>
> > Shouldn't the paths from ldd be for example /lib/libc.so.6 ?
>
> No, the cross-version of ldd shows the full path name in the cross
> environment.
>
> > Anybody has any idea what that could be?
>
> Incompatibility of libraries. Use ELDK 3.x with 2.4 kernels, and ELDK
> 4.x with 2.6 kernels; anything else is asking for trouble.
>
> Best regards,
>
> Wolfgang Denk

-- 
Thomas Maenner
E-Mail: mailto:tmaenner@aehr.com

PPC login puzzle

[Charles Krinke]

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

Re: PPC login puzzle

[Bill Gatliff]

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

RE: PPC login puzzle

[Charles Krinke]

=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

Re: PPC login puzzle

[Steve Iribarne (GMail)]

[-- Attachment #1: Type: text/plain, Size: 1022 bytes --]

<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)
*/

[-- Attachment #2: Type: text/html, Size: 1313 bytes --]

RE: PPC login puzzle

[Charles Krinke]

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

Re: PPC login puzzle

[Bill Gatliff]

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

Re: PPC login puzzle

[Wolfgang Denk]

In message <9F3F0A752CAEBE4FA7E906CC2FBFF57C069B6B@MERCURY.inside.istor.com> you wrote:
>
> 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?"

Different settings of "disable = ..." in the /etc/xinetd.d/telnet
config file?

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
"It is easier to port a shell than a shell script."      - Larry Wall

Re: PPC login puzzle

[Steve Iribarne (GMail)]

[-- Attachment #1: Type: text/plain, Size: 2353 bytes --]

On 3/31/07, Charles Krinke <ckrinke@istor.com> 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)
*/

[-- Attachment #2: Type: text/html, Size: 3086 bytes --]

Re: PPC login puzzle

[Eric Nuckols]

>
>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