Skip to contentSkip to conversation

: don't use functions marked by SUSv3 as legacy

PATCH In review Arkadiusz Miskiewicz 3 participants 8 messages Jul 1, 2007 – Jul 2, 2007

lore
Share & tools
lore
author
#2 lore raw
Quoted 6 lines · Alasdair G Kergon
Quoted 3 lines · Arkadiusz Miskiewicz

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

Quoted 1 line

Alasdair

Signature · 2 lines
Arkadiusz Mi�kiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/
#3 lore raw

On 1 Jul 2007, Arkadiusz Miskiewicz stated:

Quoted 2 lines

The other one puts LDFLAGS (linker flags) not CFLAGS (cflags is for compilation, ldflags for linking)

That's sane.

Quoted 2 lines

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?

Signature · 3 lines
`... in the sense that dragons logically follow evolution so they would
 be able to wield metal.' --- Kenneth Eng's colourless green ideas sleep
 furiously
#4 lore raw
Quoted 2 lines · Nix

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

Signature · 1 line
[email protected]
#5 lore raw

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

Quoted 6 lines · Nix
Quoted 2 lines

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

Signature · 3 lines
`... in the sense that dragons logically follow evolution so they would
 be able to wield metal.' --- Kenneth Eng's colourless green ideas sleep
 furiously
#6 lore raw
In reply to Arkadiusz Miskiewicz
Quoted 2 lines · Arkadiusz Miskiewicz

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

Yep.

Quoted 3 lines

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!

Quoted 2 lines

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

Quoted 1 line

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.

Quoted 1 line

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

OK

Quoted 1 line

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

Signature · 1 line
[email protected]
author
#7 lore raw
Quoted 6 lines · Alasdair G Kergon
Quoted 3 lines

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.

Quoted 6 lines
Quoted 3 lines

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?

Quoted 5 lines
Quoted 2 lines

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.

Quoted 10 lines
Quoted 1 line

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.

Quoted 1 line

Alasdair

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