compiling problems

compiling problems

[Miles Roper]

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?

Cheers

Miles

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

Re: compiling problems

[Greg KH]

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

Re: compiling problems

[Kay Sievers]

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

Re: compiling problems

[Greg KH]

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

Re: compiling problems

[Kay Sievers]

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

RE: compiling problems

[Miles Roper]

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

RE: compiling problems

[Miles Roper]

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

RE: compiling problems

[Richard Troth]

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

Re: compiling problems

[Greg KH]

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

RE: compiling problems

[Miles Roper]

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

Re: compiling problems

[Greg KH]

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

Re: compiling problems

[Kay Sievers]

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

Re: compiling problems

[Greg KH]

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

RE: compiling problems

[Miles Roper]

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

RE: compiling problems

[Miles Roper]

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

Re: compiling problems

[Greg KH]

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

RE: compiling problems

[Miles Roper]

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

Re: compiling problems

[Greg KH]

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

Re: compiling problems

[Chris Larson]

* 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

RE: compiling problems

[Miles Roper]

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