[linux-lvm] [PATCH]: don't use functions marked by SUSv3 as legacy

[linux-lvm] [PATCH]: don't use functions marked by SUSv3 as legacy

[Arkadiusz Miskiewicz]

Please merge this one:
http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/lvm2-susv3.patch
by qboosh/pld-linux.org.

-- 
Arkadiusz Mi�kiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/

Re: [linux-lvm] [PATCH]: don't use functions marked by SUSv3 as legacy

[Alasdair G Kergon]

On Sun, Jul 01, 2007 at 03:29:08PM +0200, Arkadiusz Miskiewicz wrote:
> Please merge this one:
> http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/lvm2-susv3.patch
> by qboosh/pld-linux.org.

Will do.  I was brought up on BSD:-)

Alasdair
-- 
agk@redhat.com

Re: [linux-lvm] [PATCH]: don't use functions marked by SUSv3 as legacy

[Arkadiusz Miskiewicz]

On Sunday 01 of July 2007, Alasdair G Kergon wrote:
> On Sun, Jul 01, 2007 at 03:29:08PM +0200, Arkadiusz Miskiewicz wrote:
> > Please merge this one:
> > http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/lvm2-susv3.patch
> > by qboosh/pld-linux.org.
>
> Will do.  I was brought up on BSD:-)

Please merge this one, too:
http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/lvm2-as-needed.patch

First it checks for tinfo library in case where ncurses is built in form of 
two libraries (tinfo - terminal stuff, ncurses - the rest).

The other one puts LDFLAGS (linker flags) not CFLAGS (cflags is for 
compilation, ldflags for linking) and changes order so linking will success 
when using -Wl,--as-needed flag.


There are also others mostly self explaining patches for device-mapper:
http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/device-mapper-disable_dynamic_link.patch
http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/device-mapper-force-local-headers.patch
http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/device-mapper-getopt.patch
http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/device-mapper-klibc.patch

> Alasdair

-- 
Arkadiusz Mi�kiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/

Re: [linux-lvm] [PATCH]: don't use functions marked by SUSv3 as legacy

[Nix]

On 1 Jul 2007, Arkadiusz Miskiewicz stated:
> The other one puts LDFLAGS (linker flags) not CFLAGS (cflags is for 
> compilation, ldflags for linking)

That's sane.

>                                   and changes order so linking will success 
> when using -Wl,--as-needed flag.

There must be more to it than this. I've always built with -Wl,--as-needed
(wired into my GCC specs file), and I've never had a problem with LVM.

I can't see how moving the -o around would change a thing, myself.

What problem does this fix?

-- 
`... in the sense that dragons logically follow evolution so they would
 be able to wield metal.' --- Kenneth Eng's colourless green ideas sleep
 furiously

Re: [linux-lvm] [PATCH]: don't use functions marked by SUSv3 as legacy

[Alasdair G Kergon]

On Sun, Jul 01, 2007 at 08:11:18PM +0100, Nix wrote:
> There must be more to it than this. I've always built with -Wl,--as-needed
> (wired into my GCC specs file), and I've never had a problem with LVM.
 
This is only changing 'fsadm' which is not enabled by default upstream
as I don't yet consider it stable.

Alasdair
-- 
agk@redhat.com

Re: [linux-lvm] [PATCH]: don't use functions marked by SUSv3 as legacy

[Nix]

On 1 Jul 2007, Alasdair G. Kergon told this:

> On Sun, Jul 01, 2007 at 08:11:18PM +0100, Nix wrote:
>> There must be more to it than this. I've always built with -Wl,--as-needed
>> (wired into my GCC specs file), and I've never had a problem with LVM.
>  
> This is only changing 'fsadm' which is not enabled by default upstream
> as I don't yet consider it stable.

I build fsadm and I don't need this patch.

(However, without this patch, including -Wl,--as-needed in the LDFLAGS
won't link fsadm with --as-needed, so it is still beneficial. I just
don't see that it's making linking work where before it didn't.)

-- 
`... in the sense that dragons logically follow evolution so they would
 be able to wield metal.' --- Kenneth Eng's colourless green ideas sleep
 furiously

Re: [linux-lvm] [PATCH]: don't use functions marked by SUSv3 as legacy

[Alasdair G Kergon]

On Sun, Jul 01, 2007 at 04:58:00PM +0200, Arkadiusz Miskiewicz wrote:
> Please merge this one, too:
> http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/lvm2-as-needed.patch
 
Yep.

> The other one puts LDFLAGS (linker flags) not CFLAGS (cflags is for 
> compilation, ldflags for linking) and changes order so linking will success 
> when using -Wl,--as-needed flag.
 
For fsadm, which I don't consider production-ready yet - but if you're
using it successfully that'd be nice to know!

> There are also others mostly self explaining patches for device-mapper:
> http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/device-mapper-disable_dynamic_link.patch

Want to test that one - how does it handle configure --disable-dynamic without
--enable-static?  (A nice error message?  Is there a cleaner way?)

> http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/device-mapper-force-local-headers.patch

Not sure what the best way to achieve that upstream is: the patch breaks some
valid alternative configurations.

> http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/device-mapper-getopt.patch

OK

> http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/device-mapper-klibc.patch

basename: I'd rather call a local implementation if 'configure' didn't find one

fread+sscanf: I'd prefer not to change that at this stage unless you can show
if fixes bugs in the existing implementation (it's not easy to get this sort of
code correct, so any change involves avoidable risk) - again an alternative
function implementation (possibly with a little refactoring) would be more
acceptable.

Alasdair
-- 
agk@redhat.com

Re: [linux-lvm] [PATCH]: don't use functions marked by SUSv3 as legacy

[Arkadiusz Miskiewicz]

On Sunday 01 of July 2007, Alasdair G Kergon wrote:

> > The other one puts LDFLAGS (linker flags) not CFLAGS (cflags is for
> > compilation, ldflags for linking) and changes order so linking will
> > success when using -Wl,--as-needed flag.
>
> For fsadm, which I don't consider production-ready yet - but if you're
> using it successfully that'd be nice to know!

Never tested but we are building it and the patch is needed for that.

> > There are also others mostly self explaining patches for device-mapper:
> > http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/device-mapper-disable_dyn
> >amic_link.patch
>
> Want to test that one - how does it handle configure --disable-dynamic
> without --enable-static?  (A nice error message?  Is there a cleaner way?)

The goal of this was disabling building shared libraries and linking to them. 
Cleaner way would be simply change --enable-static_link to do the same.

Right now you can't just build static libraries, even 
with --enable-static_link shared lib is being built:

klcc -static -shared -Wl,-soname,libdevmapper.so.1.02 \
        -O2 -fno-strict-aliasing -fwrapv -march=x86-64 -gdwarf-2 -g2  -fPIC
-Wall -Wundef -Wshadow -Wcast-align -Wwrite-strings -Wmissing-prototypes
-Wmissing-declarations -Wnested-externs -Winline -O2 -fno-strict-aliasing
-fwrapv -march=x86-64 -gdwarf-2 -g2  -Wl,--as-needed 
-Wl,--version-script,.export.sym -L../lib/ioctl datastruct/bitset.o 
datastruct/hash.o libdm-common.o libdm-file.o libdm-deptree.o libdm-string.o 
libdm-report.o mm/dbg_malloc.o mm/pool.o regex/matcher.o regex/parse_rx.o 
regex/ttree.o ioctl/libdm-iface.o  -o ioctl/libdevmapper.so

Is changing --enable-static_link to disable building shared libs a fine 
change?

> > http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/device-mapper-force-local
> >-headers.patch
>
> Not sure what the best way to achieve that upstream is: the patch breaks
> some valid alternative configurations.

AFAIK the problem was that it was prefering system wide header over local in 
package. So when building new version of device-mapper old system include 
header was used.

> > http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/device-mapper-klibc.patch
>
> basename: I'd rather call a local implementation if 'configure' didn't find
> one
>
> fread+sscanf: I'd prefer not to change that at this stage unless you can
> show if fixes bugs in the existing implementation (it's not easy to get
> this sort of code correct, so any change involves avoidable risk) - again
> an alternative function implementation (possibly with a little refactoring)
> would be more acceptable.

It doesn't fix anything. It merely replaces functions with these available in 
klibc so you can build device-mapper against klibc.

> Alasdair

-- 
Arkadiusz Mi�kiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/