* Re: compiling problems
2005-01-12 7:27 compiling problems Miles Roper
@ 2005-01-12 8:09 ` Greg KH
2005-01-12 20:03 ` Kay Sievers
` (17 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: Greg KH @ 2005-01-12 8:09 UTC (permalink / raw)
To: linux-hotplug
On Wed, Jan 12, 2005 at 08:27:04PM +1300, Miles Roper wrote:
>
> Hi,
>
> Trying to compile udev with glibc 2.1.3 and gcc 2.95.3. I use this version
> of glibc and gcc to save size as I work on an embedded thinclient software.
> No I can't use ulibc as some of the software I needs to use glibc.
>
> getting the below error
>
> gcc -pipe -DLOG -Os -fomit-frame-pointer -D_GNU_SOURCE -Wall -Wshadow
> -Wstric
> t-prototypes -Wmissing-prototypes -Wmissing-declarations
> -I/usr/local/lib/gcc
> -lib/i586-pc-linux-gnu/2.95.3/include -I/source/udev-050/libsysfs/sysfs
> -I/so
> urce/udev-050/libsysfs -c -o libsysfs/dlist.o libsysfs/dlist.c
> libsysfs/dlist.c: In function `dlist_sort_custom':
> libsysfs/dlist.c:550: parse error before `struct'
> libsysfs/dlist.c:555: `listsource' undeclared (first use in this function)
> libsysfs/dlist.c:555: (Each undeclared identifier is reported only once
> libsysfs/dlist.c:555: for each function it appears in.)
> libsysfs/dlist.c:556: `listdest' undeclared (first use in this function)
> libsysfs/dlist.c:556: `templist' undeclared (first use in this function)
> libsysfs/dlist.c:563: `mergecount' undeclared (first use in this function)
> libsysfs/dlist.c:565: `passcount' undeclared (first use in this function)
> libsysfs/dlist.c:570: `swap' undeclared (first use in this function)
> make: *** [libsysfs/dlist.o] Error 1
>
> ideas?
The patch below should fix up the gcc issues. But you will then get the
following one:
udev_add.c: In function `rename_net_if':
udev_add.c:271: structure has no member named `ifr_newname'
udev_add.c:271: structure has no member named `ifr_newname'
udev_add.c:271: structure has no member named `ifr_newname'
udev_add.c:271: structure has no member named `ifr_newname'
which is a glibc issue that I don't know how to resolve. I suggest
building using the klibc that comes with udev and see if that fixes the issue.
Hope this helps,
greg k-h
=== libsysfs/dlist.c 1.5 vs edited ==--- 1.5/libsysfs/dlist.c 2004-10-19 20:15:26 -07:00
+++ edited/libsysfs/dlist.c 2005-01-12 00:02:40 -08:00
@@ -546,11 +546,14 @@ int _dlist_merge(struct dlist *listsourc
void dlist_sort_custom(struct dlist *list, int (*compare)(void *, void *))
{
- dlist_start(list);
struct dlist *listsource, *listdest, *swap;
- struct dlist *templist = dlist_new(list->data_size);
+ struct dlist *templist;
unsigned int passcount = 1;
unsigned int mergecount = 1;
+
+ dlist_start(list);
+ templist = dlist_new(list->data_size);
+
// do nothing if there isn't anything to sort
listsource = list;
listdest = templist;
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: compiling problems
2005-01-12 7:27 compiling problems Miles Roper
2005-01-12 8:09 ` Greg KH
@ 2005-01-12 20:03 ` Kay Sievers
2005-01-12 21:43 ` Greg KH
` (16 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: Kay Sievers @ 2005-01-12 20:03 UTC (permalink / raw)
To: linux-hotplug
On Wed, 2005-01-12 at 00:09 -0800, Greg KH wrote:
> On Wed, Jan 12, 2005 at 08:27:04PM +1300, Miles Roper wrote:
> > Trying to compile udev with glibc 2.1.3 and gcc 2.95.3. I use this version
> > of glibc and gcc to save size as I work on an embedded thinclient software.
> > No I can't use ulibc as some of the software I needs to use glibc.
> >
> > getting the below error
> >
> > gcc -pipe -DLOG -Os -fomit-frame-pointer -D_GNU_SOURCE -Wall -Wshadow
> > -Wstric
> > t-prototypes -Wmissing-prototypes -Wmissing-declarations
> > -I/usr/local/lib/gcc
> > -lib/i586-pc-linux-gnu/2.95.3/include -I/source/udev-050/libsysfs/sysfs
> > -I/so
> > urce/udev-050/libsysfs -c -o libsysfs/dlist.o libsysfs/dlist.c
> > libsysfs/dlist.c: In function `dlist_sort_custom':
> > libsysfs/dlist.c:550: parse error before `struct'
> > libsysfs/dlist.c:555: `listsource' undeclared (first use in this function)
> > libsysfs/dlist.c:555: (Each undeclared identifier is reported only once
> > libsysfs/dlist.c:555: for each function it appears in.)
> > libsysfs/dlist.c:556: `listdest' undeclared (first use in this function)
> > libsysfs/dlist.c:556: `templist' undeclared (first use in this function)
> > libsysfs/dlist.c:563: `mergecount' undeclared (first use in this function)
> > libsysfs/dlist.c:565: `passcount' undeclared (first use in this function)
> > libsysfs/dlist.c:570: `swap' undeclared (first use in this function)
> > make: *** [libsysfs/dlist.o] Error 1
> >
> > ideas?
>
> The patch below should fix up the gcc issues. But you will then get the
> following one:
> udev_add.c: In function `rename_net_if':
> udev_add.c:271: structure has no member named `ifr_newname'
> udev_add.c:271: structure has no member named `ifr_newname'
> udev_add.c:271: structure has no member named `ifr_newname'
> udev_add.c:271: structure has no member named `ifr_newname'
>
> which is a glibc issue that I don't know how to resolve. I suggest
> building using the klibc that comes with udev and see if that fixes the issue.
Just a very bad hack for your ancient glibc, but seems to work. :)
Kay
=== udev_add.c 1.87 vs edited ==--- 1.87/udev_add.c 2004-12-20 00:57:30 +01:00
+++ edited/udev_add.c 2005-01-12 20:59:16 +01:00
@@ -268,7 +268,8 @@
memset(&ifr, 0x00, sizeof(struct ifreq));
strfieldcpy(ifr.ifr_name, udev->kernel_name);
- strfieldcpy(ifr.ifr_newname, udev->name);
+ //strfieldcpy(ifr.ifr_newname, udev->name);
+ strfieldcpy(ifr.ifr_ifru.ifru_data, udev->name);
retval = ioctl(sk, SIOCSIFNAME, &ifr);
if (retval != 0)
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: compiling problems
2005-01-12 7:27 compiling problems Miles Roper
2005-01-12 8:09 ` Greg KH
2005-01-12 20:03 ` Kay Sievers
@ 2005-01-12 21:43 ` Greg KH
2005-01-13 0:20 ` Kay Sievers
` (15 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: Greg KH @ 2005-01-12 21:43 UTC (permalink / raw)
To: linux-hotplug
On Wed, Jan 12, 2005 at 09:03:28PM +0100, Kay Sievers wrote:
> On Wed, 2005-01-12 at 00:09 -0800, Greg KH wrote:
> > The patch below should fix up the gcc issues. But you will then get the
> > following one:
> > udev_add.c: In function `rename_net_if':
> > udev_add.c:271: structure has no member named `ifr_newname'
> > udev_add.c:271: structure has no member named `ifr_newname'
> > udev_add.c:271: structure has no member named `ifr_newname'
> > udev_add.c:271: structure has no member named `ifr_newname'
> >
> > which is a glibc issue that I don't know how to resolve. I suggest
> > building using the klibc that comes with udev and see if that fixes the issue.
>
> Just a very bad hack for your ancient glibc, but seems to work. :)
>
> Kay
>
> === udev_add.c 1.87 vs edited ==> --- 1.87/udev_add.c 2004-12-20 00:57:30 +01:00
> +++ edited/udev_add.c 2005-01-12 20:59:16 +01:00
> @@ -268,7 +268,8 @@
>
> memset(&ifr, 0x00, sizeof(struct ifreq));
> strfieldcpy(ifr.ifr_name, udev->kernel_name);
> - strfieldcpy(ifr.ifr_newname, udev->name);
> + //strfieldcpy(ifr.ifr_newname, udev->name);
> + strfieldcpy(ifr.ifr_ifru.ifru_data, udev->name);
>
> retval = ioctl(sk, SIOCSIFNAME, &ifr);
> if (retval != 0)
>
>
Hm, any way to make this work for both libc versions? Or is this a
glibc issue that we shouldn't try to work around?
thanks,
greg k-h
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: compiling problems
2005-01-12 7:27 compiling problems Miles Roper
` (2 preceding siblings ...)
2005-01-12 21:43 ` Greg KH
@ 2005-01-13 0:20 ` Kay Sievers
2005-01-13 6:29 ` Miles Roper
` (14 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: Kay Sievers @ 2005-01-13 0:20 UTC (permalink / raw)
To: linux-hotplug
On Wed, 2005-01-12 at 13:43 -0800, Greg KH wrote:
> On Wed, Jan 12, 2005 at 09:03:28PM +0100, Kay Sievers wrote:
> > On Wed, 2005-01-12 at 00:09 -0800, Greg KH wrote:
> > > The patch below should fix up the gcc issues. But you will then get the
> > > following one:
> > > udev_add.c: In function `rename_net_if':
> > > udev_add.c:271: structure has no member named `ifr_newname'
> > > udev_add.c:271: structure has no member named `ifr_newname'
> > > udev_add.c:271: structure has no member named `ifr_newname'
> > > udev_add.c:271: structure has no member named `ifr_newname'
> > >
> > > which is a glibc issue that I don't know how to resolve. I suggest
> > > building using the klibc that comes with udev and see if that fixes the issue.
> >
> > Just a very bad hack for your ancient glibc, but seems to work. :)
> >
> > === udev_add.c 1.87 vs edited ==> > --- 1.87/udev_add.c 2004-12-20 00:57:30 +01:00
> > +++ edited/udev_add.c 2005-01-12 20:59:16 +01:00
> > @@ -268,7 +268,8 @@
> >
> > memset(&ifr, 0x00, sizeof(struct ifreq));
> > strfieldcpy(ifr.ifr_name, udev->kernel_name);
> > - strfieldcpy(ifr.ifr_newname, udev->name);
> > + //strfieldcpy(ifr.ifr_newname, udev->name);
> > + strfieldcpy(ifr.ifr_ifru.ifru_data, udev->name);
> >
> > retval = ioctl(sk, SIOCSIFNAME, &ifr);
> > if (retval != 0)
> >
> >
>
> Hm, any way to make this work for both libc versions? Or is this a
> glibc issue that we shouldn't try to work around?
Hmm, I think we should not support that officially by ifdefs and version
magic. The needed bits are added to glibc 2.1.9* in the year 2000.
Or where do you think, we should we draw the line?
Thanks,
Kay
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 20+ messages in thread* RE: compiling problems
2005-01-12 7:27 compiling problems Miles Roper
` (3 preceding siblings ...)
2005-01-13 0:20 ` Kay Sievers
@ 2005-01-13 6:29 ` Miles Roper
2005-01-13 8:53 ` Miles Roper
` (13 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: Miles Roper @ 2005-01-13 6:29 UTC (permalink / raw)
To: linux-hotplug
thanks heaps guys :o) I'll try and let you know
.....just my 2 cents on Kay's question
glic 2.1.3 is still used a bit by memory conservatve releases as 2.2 or 2.3
is quite a bit bigger. gcc 2.95.3 is the only gcc which I've found seems to
work properly with glibc 2.1.3.
the project I work on is called thinstation and 500k is a big thing for a
16/32 meg machine. thinstation is a thinclient piece of software which
allow you to recylce old (and new) hardware to connect to a server.
I would like to use ulibc at some stage, however have several problems with
this, often things don't compile for one. second is I will still need a
version of glibc anyhow for closed source problems which thinstation
supports, ie ica/tarentella/nx
note that I can compile kernel 2.6 with gcc 2.95.3 with no problems. most
(although not all) programs I've come across work with glibc 2.1.3 including
xorg 6.8.1
-----Original Message-----
From: Kay Sievers [mailto:kay.sievers@vrfy.org]
Sent: Thursday, 13 January 2005 01:21 p.m.
To: Greg KH
Cc: Miles Roper; 'linux-hotplug-devel@lists.sourceforge.net'
Subject: Re: compiling problems
On Wed, 2005-01-12 at 13:43 -0800, Greg KH wrote:
> On Wed, Jan 12, 2005 at 09:03:28PM +0100, Kay Sievers wrote:
> > On Wed, 2005-01-12 at 00:09 -0800, Greg KH wrote:
> > > The patch below should fix up the gcc issues. But you will then
> > > get the following one:
> > > udev_add.c: In function `rename_net_if':
> > > udev_add.c:271: structure has no member named `ifr_newname'
> > > udev_add.c:271: structure has no member named `ifr_newname'
> > > udev_add.c:271: structure has no member named `ifr_newname'
> > > udev_add.c:271: structure has no member named `ifr_newname'
> > >
> > > which is a glibc issue that I don't know how to resolve. I
> > > suggest building using the klibc that comes with udev and see if that
fixes the issue.
> >
> > Just a very bad hack for your ancient glibc, but seems to work. :)
> >
> > === udev_add.c 1.87 vs edited ==> > --- 1.87/udev_add.c 2004-12-20 00:57:30 +01:00
> > +++ edited/udev_add.c 2005-01-12 20:59:16 +01:00
> > @@ -268,7 +268,8 @@
> >
> > memset(&ifr, 0x00, sizeof(struct ifreq));
> > strfieldcpy(ifr.ifr_name, udev->kernel_name);
> > - strfieldcpy(ifr.ifr_newname, udev->name);
> > + //strfieldcpy(ifr.ifr_newname, udev->name);
> > + strfieldcpy(ifr.ifr_ifru.ifru_data, udev->name);
> >
> > retval = ioctl(sk, SIOCSIFNAME, &ifr);
> > if (retval != 0)
> >
> >
>
> Hm, any way to make this work for both libc versions? Or is this a
> glibc issue that we shouldn't try to work around?
Hmm, I think we should not support that officially by ifdefs and version
magic. The needed bits are added to glibc 2.1.9* in the year 2000.
Or where do you think, we should we draw the line?
Thanks,
Kay
=========================
Attention:
The information contained in this message and/or attachments is intended
only for the person or entity to which it is addressed and may contain
confidential and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon,
this information by person or entities other than the intended recipient
is prohibited. If you receive this in error, please contact the sender and delete the material from your system and destroy any copies.
=========================
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 20+ messages in thread* RE: compiling problems
2005-01-12 7:27 compiling problems Miles Roper
` (4 preceding siblings ...)
2005-01-13 6:29 ` Miles Roper
@ 2005-01-13 8:53 ` Miles Roper
2005-01-13 16:41 ` Richard Troth
` (12 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: Miles Roper @ 2005-01-13 8:53 UTC (permalink / raw)
To: linux-hotplug
ok, get this now
Compiling udevsend.c:
[ERROR]
gcc -pipe -DLOG -Os -fomit-frame-pointer -D_GNU_SOURCE -Wall -Wshadow
-Wstric
t-prototypes -Wmissing-prototypes -Wmissing-declarations
-I/usr/local/lib/gcc
-lib/i586-pc-linux-gnu/2.95.3/include -I/source/udev-050/libsysfs/sysfs
-I/so
urce/udev-050/libsysfs -c -o udevsend.o udevsend.c
In file included from udevsend.c:40:
udevd.h:52: field `envbuf' has incomplete type
ideas? :o)
-----Original Message-----
From: Kay Sievers [mailto:kay.sievers@vrfy.org]
Sent: Thursday, 13 January 2005 09:03 a.m.
To: Greg KH
Cc: Miles Roper; 'linux-hotplug-devel@lists.sourceforge.net'
Subject: Re: compiling problems
On Wed, 2005-01-12 at 00:09 -0800, Greg KH wrote:
> On Wed, Jan 12, 2005 at 08:27:04PM +1300, Miles Roper wrote:
> > Trying to compile udev with glibc 2.1.3 and gcc 2.95.3. I use this
> > version of glibc and gcc to save size as I work on an embedded
thinclient software.
> > No I can't use ulibc as some of the software I needs to use glibc.
> >
> > getting the below error
> >
> > gcc -pipe -DLOG -Os -fomit-frame-pointer -D_GNU_SOURCE -Wall
> > -Wshadow -Wstric
> > t-prototypes -Wmissing-prototypes -Wmissing-declarations
> > -I/usr/local/lib/gcc
> > -lib/i586-pc-linux-gnu/2.95.3/include
> > -I/source/udev-050/libsysfs/sysfs -I/so
> > urce/udev-050/libsysfs -c -o libsysfs/dlist.o libsysfs/dlist.c
> > libsysfs/dlist.c: In function `dlist_sort_custom':
> > libsysfs/dlist.c:550: parse error before `struct'
> > libsysfs/dlist.c:555: `listsource' undeclared (first use in this
function)
> > libsysfs/dlist.c:555: (Each undeclared identifier is reported only
once
> > libsysfs/dlist.c:555: for each function it appears in.)
> > libsysfs/dlist.c:556: `listdest' undeclared (first use in this
function)
> > libsysfs/dlist.c:556: `templist' undeclared (first use in this
function)
> > libsysfs/dlist.c:563: `mergecount' undeclared (first use in this
function)
> > libsysfs/dlist.c:565: `passcount' undeclared (first use in this
function)
> > libsysfs/dlist.c:570: `swap' undeclared (first use in this
> > function)
> > make: *** [libsysfs/dlist.o] Error 1
> >
> > ideas?
>
> The patch below should fix up the gcc issues. But you will then get
> the following one:
> udev_add.c: In function `rename_net_if':
> udev_add.c:271: structure has no member named `ifr_newname'
> udev_add.c:271: structure has no member named `ifr_newname'
> udev_add.c:271: structure has no member named `ifr_newname'
> udev_add.c:271: structure has no member named `ifr_newname'
>
> which is a glibc issue that I don't know how to resolve. I suggest
> building using the klibc that comes with udev and see if that fixes the
issue.
Just a very bad hack for your ancient glibc, but seems to work. :)
Kay
=== udev_add.c 1.87 vs edited ==--- 1.87/udev_add.c 2004-12-20 00:57:30 +01:00
+++ edited/udev_add.c 2005-01-12 20:59:16 +01:00
@@ -268,7 +268,8 @@
memset(&ifr, 0x00, sizeof(struct ifreq));
strfieldcpy(ifr.ifr_name, udev->kernel_name);
- strfieldcpy(ifr.ifr_newname, udev->name);
+ //strfieldcpy(ifr.ifr_newname, udev->name);
+ strfieldcpy(ifr.ifr_ifru.ifru_data, udev->name);
retval = ioctl(sk, SIOCSIFNAME, &ifr);
if (retval != 0)
=========================
Attention:
The information contained in this message and/or attachments is intended
only for the person or entity to which it is addressed and may contain
confidential and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon,
this information by person or entities other than the intended recipient
is prohibited. If you receive this in error, please contact the sender and delete the material from your system and destroy any copies.
=========================
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 20+ messages in thread* RE: compiling problems
2005-01-12 7:27 compiling problems Miles Roper
` (5 preceding siblings ...)
2005-01-13 8:53 ` Miles Roper
@ 2005-01-13 16:41 ` Richard Troth
2005-01-13 17:17 ` Greg KH
` (11 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: Richard Troth @ 2005-01-13 16:41 UTC (permalink / raw)
To: linux-hotplug
Kay said:
>> Hmm, I think we should not support that officially by ifdefs
>> and version magic. The needed bits are added to glibc 2.1.9*
>> in the year 2000.
>>
>> Or where do you think, we should we draw the line?
Then Miles wrote:
> glic 2.1.3 is still used a bit by memory conservatve releases
> as 2.2 or 2.3 is quite a bit bigger. gcc 2.95.3 is the only gcc
> which I've found seems to work properly with glibc 2.1.3.
I affirm Miles' comments.
Some "tight" systems are stuck here.
On such systems, we can build newer releases of many things,
but upgrading GLIBC and GCC just won't work. (Not today, anyway.)
I have such machines doing production work. (Granted, not widely.)
[interesting discussion of thinstation omitted for brevity]
> I would like to use ulibc at some stage, however have several
> problems with this, often things don't compile for one.
> second is I will still need a version of glibc anyhow
> for closed source problems which thinstation
> supports, ie ica/tarentella/nx
I have not done ulibc either, but more for lack of time.
> note that I can compile kernel 2.6 with gcc 2.95.3 with no problems.
> most (although not all) programs I've come across work with
> glibc 2.1.3 including xorg 6.8.1
Good news to hear!
Thanks for the report.
-- R;
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: compiling problems
2005-01-12 7:27 compiling problems Miles Roper
` (6 preceding siblings ...)
2005-01-13 16:41 ` Richard Troth
@ 2005-01-13 17:17 ` Greg KH
2005-01-14 7:51 ` Miles Roper
` (10 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: Greg KH @ 2005-01-13 17:17 UTC (permalink / raw)
To: linux-hotplug
On Thu, Jan 13, 2005 at 10:41:50AM -0600, Richard Troth wrote:
> Kay said:
> >> Hmm, I think we should not support that officially by ifdefs
> >> and version magic. The needed bits are added to glibc 2.1.9*
> >> in the year 2000.
> >>
> >> Or where do you think, we should we draw the line?
>
> Then Miles wrote:
> > glic 2.1.3 is still used a bit by memory conservatve releases
> > as 2.2 or 2.3 is quite a bit bigger. gcc 2.95.3 is the only gcc
> > which I've found seems to work properly with glibc 2.1.3.
>
> I affirm Miles' comments.
> Some "tight" systems are stuck here.
> On such systems, we can build newer releases of many things,
> but upgrading GLIBC and GCC just won't work. (Not today, anyway.)
> I have such machines doing production work. (Granted, not widely.)
Why not just use the version of klibc to build udev against in these
situations? It's easy:
make USE_KLIBC=true
That's what I have done on my one old box that still has an old version
of glibc.
I don't think we should be adding work arounds for this kind of stuff,
due to this built-in solution. Unless that doesn't work for anyone
else?
thanks,
greg k-h
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 20+ messages in thread* RE: compiling problems
2005-01-12 7:27 compiling problems Miles Roper
` (7 preceding siblings ...)
2005-01-13 17:17 ` Greg KH
@ 2005-01-14 7:51 ` Miles Roper
2005-01-19 19:41 ` Greg KH
` (9 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: Miles Roper @ 2005-01-14 7:51 UTC (permalink / raw)
To: linux-hotplug
this is what I get when doing a make USE_KLIBC=true
bash# make USE_KLIBC=true
make -C klibc SUBDIRS=klibc TESTSmake[1]: Entering directory `/source/udev-050/klibc'
make[2]: Entering directory `/source/udev-050/klibc/klibc'
gcc -Wp,-MT,arch/i386/crt0.o,-MD,arch/i386/.crt0.o.d -march=i386 -Os -g
-malign-functions=0 -malign-jumps=0 -malign-loops=0 -nostdinc -iwithprefix
include -D__KLIBC__ -DBITSIZE2 -I../include/arch/i386 -I../include/bits32
-I../include -I../linux/include -I../linux/include2 -I../linux/include
-DWITH_ERRLIST -W -Wall -Wpointer-arith -Wwrite-strings -Wstrict-prototypes
-Winline -D__ASSEMBLY__ -c -o arch/i386/crt0.o arch/i386/crt0.S
Usage: cpp0 [switches] input output
Switches:
-include <file> Include the contents of <file> before other
files
-imacros <file> Accept definition of marcos in <file>
-iprefix <path> Specify <path> as a prefix for next two options
-iwithprefix <dir> Add <dir> to the end of the system include paths
-iwithprefixbefore <dir> Add <dir> to the end of the main include paths
-isystem <dir> Add <dir> to the start of the system include
paths
-idirafter <dir> Add <dir> to the end of the system include paths
-I <dir> Add <dir> to the end of the main include paths
-nostdinc Do not search the system include directories
-nostdinc++ Do not search the system include directories for
C++
-o <file> Put output into <file>
-pedantic Issue all warnings demanded by strict ANSI C
-traditional Follow K&R pre-processor behaviour
-trigraphs Support ANSI C trigraphs
-lang-c Assume that the input sources are in C
-lang-c89 Assume that the input is C89; depricated
-lang-c++ Assume that the input sources are in C++
-lang-objc Assume that the input sources are in ObjectiveC
-lang-objc++ Assume that the input sources are in
ObjectiveC++
-lang-asm Assume that the input sources are in assembler
-lang-chill Assume that the input sources are in Chill
-std=<std name> Specify the conformance standard; one of:
gnu89, gnu9x, c89, c9x, iso9899:1990,
iso9899:199409, iso9899:199x
-+ Allow parsing of C++ style features
-w Inhibit warning messages
-Wtrigraphs Warn if trigraphs are encountered
-Wno-trigraphs Do not warn about trigraphs
-Wcomment{s} Warn if one comment starts inside another
-Wno-comment{s} Do not warn about comments
-Wtraditional Warn if a macro argument is/would be turned into
a string if -traditional is specified
-Wno-traditional Do not warn about stringification
-Wundef Warn if an undefined macro is used by #if
-Wno-undef Do not warn about testing undefined macros
-Wimport Warn about the use of the #import directive
-Wno-import Do not warn about the use of #import
-Werror Treat all warnings as errors
-Wno-error Do not treat warnings as errors
-Wall Enable all preprocessor warnings
-M Generate make dependencies
-MM As -M, but ignore system header files
-MD As -M, but put output in a .d file
-MMD As -MD, but ignore system header files
-MG Treat missing header file as generated files
-g Include #define and #undef directives in the
output
-D<macro> Define a <macro> with string '1' as its value
-D<macro>=<val> Define a <macro> with <val> as its value
-A<question> (<answer>) Assert the <answer> to <question>
-U<macro> Undefine <macro>
-u or -undef Do not predefine any macros
-v Display the version number
-H Print the name of header files as they are used
-C Do not discard comments
-dM Display a list of macro definitions active at
end
-dD Preserve macro definitions in output
-dN As -dD except that only the names are preserved
-dI Include #include directives in the output
-ifoutput Describe skipped code blocks in output
-P Do not generate #line directives
-$ Do not include '$' in identifiers
-remap Remap file names when including files.
-h or --help Display this information
cpp0: Too many arguments
make[2]: *** [arch/i386/crt0.o] Error 1
make[2]: Leaving directory `/source/udev-050/klibc/klibc'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/source/udev-050/klibc'
make: *** [/source/udev-050/klibc/klibc/crt0.o] Error 2
bash#
-----Original Message-----
From: Greg KH [mailto:greg@kroah.com]
Sent: Friday, 14 January 2005 06:17 a.m.
To: Richard Troth
Cc: Miles Roper; Kay Sievers; linux-hotplug-devel@lists.sourceforge.net
Subject: Re: compiling problems
On Thu, Jan 13, 2005 at 10:41:50AM -0600, Richard Troth wrote:
> Kay said:
> >> Hmm, I think we should not support that officially by ifdefs and
> >> version magic. The needed bits are added to glibc 2.1.9* in the
> >> year 2000.
> >>
> >> Or where do you think, we should we draw the line?
>
> Then Miles wrote:
> > glic 2.1.3 is still used a bit by memory conservatve releases as 2.2
> > or 2.3 is quite a bit bigger. gcc 2.95.3 is the only gcc which I've
> > found seems to work properly with glibc 2.1.3.
>
> I affirm Miles' comments.
> Some "tight" systems are stuck here.
> On such systems, we can build newer releases of many things,
> but upgrading GLIBC and GCC just won't work. (Not today, anyway.)
> I have such machines doing production work. (Granted, not widely.)
Why not just use the version of klibc to build udev against in these
situations? It's easy:
make USE_KLIBC=true
That's what I have done on my one old box that still has an old version of
glibc.
I don't think we should be adding work arounds for this kind of stuff, due
to this built-in solution. Unless that doesn't work for anyone else?
thanks,
greg k-h
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE
limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
=========================
Attention:
The information contained in this message and/or attachments is intended
only for the person or entity to which it is addressed and may contain
confidential and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon,
this information by person or entities other than the intended recipient
is prohibited. If you receive this in error, please contact the sender and delete the material from your system and destroy any copies.
=========================
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: compiling problems
2005-01-12 7:27 compiling problems Miles Roper
` (8 preceding siblings ...)
2005-01-14 7:51 ` Miles Roper
@ 2005-01-19 19:41 ` Greg KH
2005-01-19 21:06 ` Kay Sievers
` (8 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: Greg KH @ 2005-01-19 19:41 UTC (permalink / raw)
To: linux-hotplug
On Fri, Jan 14, 2005 at 08:51:41PM +1300, Miles Roper wrote:
>
> this is what I get when doing a make USE_KLIBC=true
>
> bash# make USE_KLIBC=true
> make -C klibc SUBDIRS=klibc TESTS> make[1]: Entering directory `/source/udev-050/klibc'
> make[2]: Entering directory `/source/udev-050/klibc/klibc'
> gcc -Wp,-MT,arch/i386/crt0.o,-MD,arch/i386/.crt0.o.d -march=i386 -Os -g
> -malign-functions=0 -malign-jumps=0 -malign-loops=0 -nostdinc -iwithprefix
> include -D__KLIBC__ -DBITSIZE2 -I../include/arch/i386 -I../include/bits32
> -I../include -I../linux/include -I../linux/include2 -I../linux/include
> -DWITH_ERRLIST -W -Wall -Wpointer-arith -Wwrite-strings -Wstrict-prototypes
> -Winline -D__ASSEMBLY__ -c -o arch/i386/crt0.o arch/i386/crt0.S
> Usage: cpp0 [switches] input output
<snip> me too. Ick. At first glance, it looks ok, but odds are there's
a command line argument that should not be there. Anyone else spot it?
thanks,
greg k-h
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: compiling problems
2005-01-12 7:27 compiling problems Miles Roper
` (9 preceding siblings ...)
2005-01-19 19:41 ` Greg KH
@ 2005-01-19 21:06 ` Kay Sievers
2005-01-19 21:31 ` Greg KH
` (7 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: Kay Sievers @ 2005-01-19 21:06 UTC (permalink / raw)
To: linux-hotplug
On Wed, 2005-01-19 at 11:41 -0800, Greg KH wrote:
> On Fri, Jan 14, 2005 at 08:51:41PM +1300, Miles Roper wrote:
> >
> > this is what I get when doing a make USE_KLIBC=true
> >
> > bash# make USE_KLIBC=true
> > make -C klibc SUBDIRS=klibc TESTS> > make[1]: Entering directory `/source/udev-050/klibc'
> > make[2]: Entering directory `/source/udev-050/klibc/klibc'
> > gcc -Wp,-MT,arch/i386/crt0.o,-MD,arch/i386/.crt0.o.d -march=i386 -Os -g
> > -malign-functions=0 -malign-jumps=0 -malign-loops=0 -nostdinc -iwithprefix
> > include -D__KLIBC__ -DBITSIZE2 -I../include/arch/i386 -I../include/bits32
> > -I../include -I../linux/include -I../linux/include2 -I../linux/include
> > -DWITH_ERRLIST -W -Wall -Wpointer-arith -Wwrite-strings -Wstrict-prototypes
> > -Winline -D__ASSEMBLY__ -c -o arch/i386/crt0.o arch/i386/crt0.S
> > Usage: cpp0 [switches] input output
>
> <snip> me too. Ick. At first glance, it looks ok, but odds are there's
> a command line argument that should not be there.
What do you mean? The TEST=? It is there to be able to call an
unmodified klibc provided Makefile.
> Anyone else spot it?
It does only happen with gcc 2.96?
3.x is working on the same box?
Thanks,
Kay
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: compiling problems
2005-01-12 7:27 compiling problems Miles Roper
` (10 preceding siblings ...)
2005-01-19 21:06 ` Kay Sievers
@ 2005-01-19 21:31 ` Greg KH
2005-01-20 8:12 ` Miles Roper
` (6 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: Greg KH @ 2005-01-19 21:31 UTC (permalink / raw)
To: linux-hotplug
On Wed, Jan 19, 2005 at 10:06:29PM +0100, Kay Sievers wrote:
> On Wed, 2005-01-19 at 11:41 -0800, Greg KH wrote:
> > On Fri, Jan 14, 2005 at 08:51:41PM +1300, Miles Roper wrote:
> > >
> > > this is what I get when doing a make USE_KLIBC=true
> > >
> > > bash# make USE_KLIBC=true
> > > make -C klibc SUBDIRS=klibc TESTS> > > make[1]: Entering directory `/source/udev-050/klibc'
> > > make[2]: Entering directory `/source/udev-050/klibc/klibc'
> > > gcc -Wp,-MT,arch/i386/crt0.o,-MD,arch/i386/.crt0.o.d -march=i386 -Os -g
> > > -malign-functions=0 -malign-jumps=0 -malign-loops=0 -nostdinc -iwithprefix
> > > include -D__KLIBC__ -DBITSIZE2 -I../include/arch/i386 -I../include/bits32
> > > -I../include -I../linux/include -I../linux/include2 -I../linux/include
> > > -DWITH_ERRLIST -W -Wall -Wpointer-arith -Wwrite-strings -Wstrict-prototypes
> > > -Winline -D__ASSEMBLY__ -c -o arch/i386/crt0.o arch/i386/crt0.S
> > > Usage: cpp0 [switches] input output
> >
> > <snip> me too. Ick. At first glance, it looks ok, but odds are there's
> > a command line argument that should not be there.
>
> What do you mean? The TEST=? It is there to be able to call an
> unmodified klibc provided Makefile.
No, turns out it's the -MT option to gcc. Thanks to hpa on the klibc
mailing list for finding it.
> > Anyone else spot it?
>
> It does only happen with gcc 2.96?
Seems like it.
> 3.x is working on the same box?
I don't have 3.x on that box to try it out :(
thanks,
greg k-h
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 20+ messages in thread* RE: compiling problems
2005-01-12 7:27 compiling problems Miles Roper
` (11 preceding siblings ...)
2005-01-19 21:31 ` Greg KH
@ 2005-01-20 8:12 ` Miles Roper
2005-01-20 8:41 ` Miles Roper
` (5 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: Miles Roper @ 2005-01-20 8:12 UTC (permalink / raw)
To: linux-hotplug
nope, still get it...
make -C klibc SUBDIRS=klibc TESTSmake[1]: Entering directory `/source/udev-050/klibc'
make[2]: Entering directory `/source/udev-050/klibc/klibc'
gcc -Wp,arch/i386/crt0.o,-MD,arch/i386/.crt0.o.d -march=i386 -Os -g
-malign-functions=0 -malign-jumps=0 -malign-loops=0 -nostdinc -iwithprefix
include -D__KLIBC__ -DBITSIZE2 -I../include/arch/i386 -I../include/bits32
-I../include -I../linux/include -I../linux/include2 -I../linux/include
-DWITH_ERRLIST -W -Wall -Wpointer-arith -Wwrite-strings -Wstrict-prototypes
-Winline -D__ASSEMBLY__ -c -o arch/i386/crt0.o arch/i386/crt0.S
Usage: cpp0 [switches] input output
Switches:
-include <file> Include the contents of <file> before other
files
-imacros <file> Accept definition of marcos in <file>
-iprefix <path> Specify <path> as a prefix for next two options
-iwithprefix <dir> Add <dir> to the end of the system include paths
-iwithprefixbefore <dir> Add <dir> to the end of the main include paths
-isystem <dir> Add <dir> to the start of the system include
paths
-idirafter <dir> Add <dir> to the end of the system include paths
-I <dir> Add <dir> to the end of the main include paths
-nostdinc Do not search the system include directories
-nostdinc++ Do not search the system include directories for
C++
-o <file> Put output into <file>
-pedantic Issue all warnings demanded by strict ANSI C
-traditional Follow K&R pre-processor behaviour
-trigraphs Support ANSI C trigraphs
-lang-c Assume that the input sources are in C
-lang-c89 Assume that the input is C89; depricated
-lang-c++ Assume that the input sources are in C++
-lang-objc Assume that the input sources are in ObjectiveC
-lang-objc++ Assume that the input sources are in
ObjectiveC++
-lang-asm Assume that the input sources are in assembler
-lang-chill Assume that the input sources are in Chill
-std=<std name> Specify the conformance standard; one of:
gnu89, gnu9x, c89, c9x, iso9899:1990,
iso9899:199409, iso9899:199x
-+ Allow parsing of C++ style features
-w Inhibit warning messages
-Wtrigraphs Warn if trigraphs are encountered
-Wno-trigraphs Do not warn about trigraphs
-Wcomment{s} Warn if one comment starts inside another
-Wno-comment{s} Do not warn about comments
-Wtraditional Warn if a macro argument is/would be turned into
a string if -traditional is specified
-Wno-traditional Do not warn about stringification
-Wundef Warn if an undefined macro is used by #if
-Wno-undef Do not warn about testing undefined macros
-Wimport Warn about the use of the #import directive
-Wno-import Do not warn about the use of #import
-Werror Treat all warnings as errors
-Wno-error Do not treat warnings as errors
-Wall Enable all preprocessor warnings
-M Generate make dependencies
-MM As -M, but ignore system header files
-MD As -M, but put output in a .d file
-MMD As -MD, but ignore system header files
-MG Treat missing header file as generated files
-g Include #define and #undef directives in the
output
-D<macro> Define a <macro> with string '1' as its value
-D<macro>=<val> Define a <macro> with <val> as its value
-A<question> (<answer>) Assert the <answer> to <question>
-U<macro> Undefine <macro>
-u or -undef Do not predefine any macros
-v Display the version number
-H Print the name of header files as they are used
-C Do not discard comments
-dM Display a list of macro definitions active at
end
-dD Preserve macro definitions in output
-dN As -dD except that only the names are preserved
-dI Include #include directives in the output
-ifoutput Describe skipped code blocks in output
-P Do not generate #line directives
-$ Do not include '$' in identifiers
-remap Remap file names when including files.
-h or --help Display this information
cpp0: Too many arguments
make[2]: *** [arch/i386/crt0.o] Error 1
make[2]: Leaving directory `/source/udev-050/klibc/klibc'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/source/udev-050/klibc'
make: *** [/source/udev-050/klibc/klibc/crt0.o] Error 2
-----Original Message-----
From: Greg KH [mailto:greg@kroah.com]
Sent: Thursday, 20 January 2005 10:32 a.m.
To: Kay Sievers
Cc: Miles Roper; Richard Troth; Hotplug Devel
Subject: Re: compiling problems
On Wed, Jan 19, 2005 at 10:06:29PM +0100, Kay Sievers wrote:
> On Wed, 2005-01-19 at 11:41 -0800, Greg KH wrote:
> > On Fri, Jan 14, 2005 at 08:51:41PM +1300, Miles Roper wrote:
> > >
> > > this is what I get when doing a make USE_KLIBC=true
> > >
> > > bash# make USE_KLIBC=true
> > > make -C klibc SUBDIRS=klibc TESTS> > > make[1]: Entering directory `/source/udev-050/klibc'
> > > make[2]: Entering directory `/source/udev-050/klibc/klibc'
> > > gcc -Wp,-MT,arch/i386/crt0.o,-MD,arch/i386/.crt0.o.d -march=i386
> > > -Os -g -malign-functions=0 -malign-jumps=0 -malign-loops=0
> > > -nostdinc -iwithprefix include -D__KLIBC__ -DBITSIZE2
> > > -I../include/arch/i386 -I../include/bits32 -I../include
> > > -I../linux/include -I../linux/include2 -I../linux/include
> > > -DWITH_ERRLIST -W -Wall -Wpointer-arith -Wwrite-strings
> > > -Wstrict-prototypes -Winline -D__ASSEMBLY__ -c -o arch/i386/crt0.o
> > > arch/i386/crt0.S
> > > Usage: cpp0 [switches] input output
> >
> > <snip> me too. Ick. At first glance, it looks ok, but odds are
> > there's a command line argument that should not be there.
>
> What do you mean? The TEST=? It is there to be able to call an
> unmodified klibc provided Makefile.
No, turns out it's the -MT option to gcc. Thanks to hpa on the klibc
mailing list for finding it.
> > Anyone else spot it?
>
> It does only happen with gcc 2.96?
Seems like it.
> 3.x is working on the same box?
I don't have 3.x on that box to try it out :(
thanks,
greg k-h
=========================
Attention:
The information contained in this message and/or attachments is intended
only for the person or entity to which it is addressed and may contain
confidential and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon,
this information by person or entities other than the intended recipient
is prohibited. If you receive this in error, please contact the sender and delete the material from your system and destroy any copies.
=========================
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 20+ messages in thread* RE: compiling problems
2005-01-12 7:27 compiling problems Miles Roper
` (12 preceding siblings ...)
2005-01-20 8:12 ` Miles Roper
@ 2005-01-20 8:41 ` Miles Roper
2005-01-20 14:27 ` Greg KH
` (4 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: Miles Roper @ 2005-01-20 8:41 UTC (permalink / raw)
To: linux-hotplug
ps, happens on 2.95.3, I don't use 2.96 (had too many problems with it)
-----Original Message-----
From: Greg KH [mailto:greg@kroah.com]
Sent: Thursday, 20 January 2005 10:32 a.m.
To: Kay Sievers
Cc: Miles Roper; Richard Troth; Hotplug Devel
Subject: Re: compiling problems
On Wed, Jan 19, 2005 at 10:06:29PM +0100, Kay Sievers wrote:
> On Wed, 2005-01-19 at 11:41 -0800, Greg KH wrote:
> > On Fri, Jan 14, 2005 at 08:51:41PM +1300, Miles Roper wrote:
> > >
> > > this is what I get when doing a make USE_KLIBC=true
> > >
> > > bash# make USE_KLIBC=true
> > > make -C klibc SUBDIRS=klibc TESTS> > > make[1]: Entering directory `/source/udev-050/klibc'
> > > make[2]: Entering directory `/source/udev-050/klibc/klibc'
> > > gcc -Wp,-MT,arch/i386/crt0.o,-MD,arch/i386/.crt0.o.d -march=i386
> > > -Os -g -malign-functions=0 -malign-jumps=0 -malign-loops=0
> > > -nostdinc -iwithprefix include -D__KLIBC__ -DBITSIZE2
> > > -I../include/arch/i386 -I../include/bits32 -I../include
> > > -I../linux/include -I../linux/include2 -I../linux/include
> > > -DWITH_ERRLIST -W -Wall -Wpointer-arith -Wwrite-strings
> > > -Wstrict-prototypes -Winline -D__ASSEMBLY__ -c -o arch/i386/crt0.o
> > > arch/i386/crt0.S
> > > Usage: cpp0 [switches] input output
> >
> > <snip> me too. Ick. At first glance, it looks ok, but odds are
> > there's a command line argument that should not be there.
>
> What do you mean? The TEST=? It is there to be able to call an
> unmodified klibc provided Makefile.
No, turns out it's the -MT option to gcc. Thanks to hpa on the klibc
mailing list for finding it.
> > Anyone else spot it?
>
> It does only happen with gcc 2.96?
Seems like it.
> 3.x is working on the same box?
I don't have 3.x on that box to try it out :(
thanks,
greg k-h
=========================
Attention:
The information contained in this message and/or attachments is intended
only for the person or entity to which it is addressed and may contain
confidential and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon,
this information by person or entities other than the intended recipient
is prohibited. If you receive this in error, please contact the sender and delete the material from your system and destroy any copies.
=========================
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: compiling problems
2005-01-12 7:27 compiling problems Miles Roper
` (13 preceding siblings ...)
2005-01-20 8:41 ` Miles Roper
@ 2005-01-20 14:27 ` Greg KH
2005-01-21 9:47 ` Miles Roper
` (3 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: Greg KH @ 2005-01-20 14:27 UTC (permalink / raw)
To: linux-hotplug
On Thu, Jan 20, 2005 at 09:41:55PM +1300, Miles Roper wrote:
>
> ps, happens on 2.95.3, I don't use 2.96 (had too many problems with it)
Yes, this is a klibc build issue, the klibc developers are looking into
how to fix it. If/when they do, we'll add those changes to the udev
version too.
So until then, sorry, I really recommend either upgrading your glibc
version, or your gcc version to build udev.
thanks,
greg k-h
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 20+ messages in thread* RE: compiling problems
2005-01-12 7:27 compiling problems Miles Roper
` (14 preceding siblings ...)
2005-01-20 14:27 ` Greg KH
@ 2005-01-21 9:47 ` Miles Roper
2005-01-21 17:05 ` Greg KH
` (2 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: Miles Roper @ 2005-01-21 9:47 UTC (permalink / raw)
To: linux-hotplug
ok, I can't change gcc/glibc, to do so is a major rework of thinstation, not
to mention the bloat it would cause. if anything I will want to move to
uclibc. oh well, looks like we are stuck with devfs for a while then :o(
If you remember, would you be able to let me know when the fix gets
implemented
thanks
Miles
-----Original Message-----
From: Greg KH [mailto:greg@kroah.com]
Sent: Friday, 21 January 2005 03:27 a.m.
To: Miles Roper
Cc: Kay Sievers; Richard Troth; Hotplug Devel
Subject: Re: compiling problems
On Thu, Jan 20, 2005 at 09:41:55PM +1300, Miles Roper wrote:
>
> ps, happens on 2.95.3, I don't use 2.96 (had too many problems with
> it)
Yes, this is a klibc build issue, the klibc developers are looking into how
to fix it. If/when they do, we'll add those changes to the udev version
too.
So until then, sorry, I really recommend either upgrading your glibc
version, or your gcc version to build udev.
thanks,
greg k-h
=========================
Attention:
The information contained in this message and/or attachments is intended
only for the person or entity to which it is addressed and may contain
confidential and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon,
this information by person or entities other than the intended recipient
is prohibited. If you receive this in error, please contact the sender and delete the material from your system and destroy any copies.
=========================
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: compiling problems
2005-01-12 7:27 compiling problems Miles Roper
` (15 preceding siblings ...)
2005-01-21 9:47 ` Miles Roper
@ 2005-01-21 17:05 ` Greg KH
2005-01-21 18:43 ` Chris Larson
2005-01-25 8:14 ` Miles Roper
18 siblings, 0 replies; 20+ messages in thread
From: Greg KH @ 2005-01-21 17:05 UTC (permalink / raw)
To: linux-hotplug
On Fri, Jan 21, 2005 at 10:47:42PM +1300, Miles Roper wrote:
>
> ok, I can't change gcc/glibc, to do so is a major rework of thinstation, not
> to mention the bloat it would cause. if anything I will want to move to
> uclibc. oh well, looks like we are stuck with devfs for a while then :o(
Wait, why not use uclibc? Are there problems building with that? I
remember we had some very early patches submitted to udev from the
uclibc developers in order to get udev to build properly with it.
Hopefully we've not broken anything since then.
Care to try it out?
thanks,
greg k-h
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: compiling problems
2005-01-12 7:27 compiling problems Miles Roper
` (16 preceding siblings ...)
2005-01-21 17:05 ` Greg KH
@ 2005-01-21 18:43 ` Chris Larson
2005-01-25 8:14 ` Miles Roper
18 siblings, 0 replies; 20+ messages in thread
From: Chris Larson @ 2005-01-21 18:43 UTC (permalink / raw)
To: linux-hotplug
* Greg KH (greg@kroah.com) wrote:
> On Fri, Jan 21, 2005 at 10:47:42PM +1300, Miles Roper wrote:
> >
> > ok, I can't change gcc/glibc, to do so is a major rework of thinstation, not
> > to mention the bloat it would cause. if anything I will want to move to
> > uclibc. oh well, looks like we are stuck with devfs for a while then :o(
>
> Wait, why not use uclibc? Are there problems building with that? I
> remember we had some very early patches submitted to udev from the
> uclibc developers in order to get udev to build properly with it.
> Hopefully we've not broken anything since then.
>
> Care to try it out?
I use uclibc on a number of my platforms. udev builds and works fine.
--
Chris Larson - kergoth at handhelds dot org
Linux Software Systems Engineer - clarson at ti dot com
Core Developer/Architect - BitBake, OpenEmbedded, OpenZaurus
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 20+ messages in thread* RE: compiling problems
2005-01-12 7:27 compiling problems Miles Roper
` (17 preceding siblings ...)
2005-01-21 18:43 ` Chris Larson
@ 2005-01-25 8:14 ` Miles Roper
18 siblings, 0 replies; 20+ messages in thread
From: Miles Roper @ 2005-01-25 8:14 UTC (permalink / raw)
To: linux-hotplug
thanks for the suggestion, but no. this adds quite a bit of overhead. when
we switch to uclibc in the future I'll look at it again.
-----Original Message-----
From: Greg KH [mailto:greg@kroah.com]
Sent: Saturday, 22 January 2005 06:05 a.m.
To: Miles Roper
Cc: Kay Sievers; Richard Troth; Hotplug Devel; Thinstation-Developer
(thinstation-developer@lists.sourceforge.net)
Subject: Re: compiling problems
On Fri, Jan 21, 2005 at 10:47:42PM +1300, Miles Roper wrote:
>
> ok, I can't change gcc/glibc, to do so is a major rework of
> thinstation, not to mention the bloat it would cause. if anything I
> will want to move to uclibc. oh well, looks like we are stuck with
> devfs for a while then :o(
Wait, why not use uclibc? Are there problems building with that? I
remember we had some very early patches submitted to udev from the uclibc
developers in order to get udev to build properly with it.
Hopefully we've not broken anything since then.
Care to try it out?
thanks,
greg k-h
=========================
Attention:
The information contained in this message and/or attachments is intended
only for the person or entity to which it is addressed and may contain
confidential and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon,
this information by person or entities other than the intended recipient
is prohibited. If you receive this in error, please contact the sender and delete the material from your system and destroy any copies.
=========================
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply [flat|nested] 20+ messages in thread