Re: [Libguestfs] [PATCH v6 05/41] utils: Split out cleanups into common/cleanups.
On Mon, Jun 19, 2017 at 11:59:11AM +0100, Richard W.M. Jones wrote: > On Mon, Jun 19, 2017 at 10:25:33AM +0200, Pino Toscano wrote: > > On Friday, 16 June 2017 16:58:53 CEST Richard W.M. Jones wrote: > > > On Fri, Jun 16, 2017 at 03:24:55PM +0200, Pino Toscano wrote: > > > > On Thursday, 15 June 2017 19:05:55 CEST Richard W.M. Jones wrote: > > > > > Those cleanups which only depend on libc, gnulib or libxml2 are split > > > > > out into a separate common/cleanups directory. > > > > > --- > > > > > > > > IMHO a single cleanups.c source should be enough, otherwise it's overly > > > > split... > > > > > > I think you do need to split it. The reason is that if the program > > > uses libcleanups.la but doesn't link to (eg) libxml2 then the link > > > will fail. We could either force everything to link unnecessarily to > > > libxml2 or we can split the object files so that the libxml2 > > > dependency is never pulled in if the main program doesn't use it. > > > > This is for the libxml2 parts though. Also, I see that the cleanups are > > split from libutils, but then > > a) libcleanups is basically used where libutils is > > b) patch #14 makes the daemon link both libcleanup and libutils > > so IMHO the libc + gnulib cleanups could simply stay where they are, > > in libutils > > OK, I'll combine gnulib cleanups back into libc cleanups. I had to split gnulib cleanups out again into a separate object file. There are some OCaml bytecode binaries that we build for testing where it is difficult to statically link with -lgnu (and not necessary either). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html ___ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs
Re: [Libguestfs] [PATCH v6 05/41] utils: Split out cleanups into common/cleanups.
On Mon, Jun 19, 2017 at 10:25:33AM +0200, Pino Toscano wrote: > On Friday, 16 June 2017 16:58:53 CEST Richard W.M. Jones wrote: > > On Fri, Jun 16, 2017 at 03:24:55PM +0200, Pino Toscano wrote: > > > On Thursday, 15 June 2017 19:05:55 CEST Richard W.M. Jones wrote: > > > > Those cleanups which only depend on libc, gnulib or libxml2 are split > > > > out into a separate common/cleanups directory. > > > > --- > > > > > > IMHO a single cleanups.c source should be enough, otherwise it's overly > > > split... > > > > I think you do need to split it. The reason is that if the program > > uses libcleanups.la but doesn't link to (eg) libxml2 then the link > > will fail. We could either force everything to link unnecessarily to > > libxml2 or we can split the object files so that the libxml2 > > dependency is never pulled in if the main program doesn't use it. > > This is for the libxml2 parts though. Also, I see that the cleanups are > split from libutils, but then > a) libcleanups is basically used where libutils is > b) patch #14 makes the daemon link both libcleanup and libutils > so IMHO the libc + gnulib cleanups could simply stay where they are, > in libutils OK, I'll combine gnulib cleanups back into libc cleanups. Also I checked and you are correct that everywhere which uses common/cleanups also uses common/utils, so I'll put cleanups back into utils. Rich. > > And the same applies (but a bit less) to gnulib. I'm not sure > > anything doesn't link to gnulib though, and probably everything should > > (except examples but they don't use cleanups). > > I think it's basically used everywhere, even more so after the switch > to getprogname (which makes gnulib needed on Linux). > > -- > Pino Toscano > ___ > Libguestfs mailing list > Libguestfs@redhat.com > https://www.redhat.com/mailman/listinfo/libguestfs -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html ___ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs
Re: [Libguestfs] [PATCH v6 05/41] utils: Split out cleanups into common/cleanups.
On Friday, 16 June 2017 16:58:53 CEST Richard W.M. Jones wrote: > On Fri, Jun 16, 2017 at 03:24:55PM +0200, Pino Toscano wrote: > > On Thursday, 15 June 2017 19:05:55 CEST Richard W.M. Jones wrote: > > > Those cleanups which only depend on libc, gnulib or libxml2 are split > > > out into a separate common/cleanups directory. > > > --- > > > > IMHO a single cleanups.c source should be enough, otherwise it's overly > > split... > > I think you do need to split it. The reason is that if the program > uses libcleanups.la but doesn't link to (eg) libxml2 then the link > will fail. We could either force everything to link unnecessarily to > libxml2 or we can split the object files so that the libxml2 > dependency is never pulled in if the main program doesn't use it. This is for the libxml2 parts though. Also, I see that the cleanups are split from libutils, but then a) libcleanups is basically used where libutils is b) patch #14 makes the daemon link both libcleanup and libutils so IMHO the libc + gnulib cleanups could simply stay where they are, in libutils > And the same applies (but a bit less) to gnulib. I'm not sure > anything doesn't link to gnulib though, and probably everything should > (except examples but they don't use cleanups). I think it's basically used everywhere, even more so after the switch to getprogname (which makes gnulib needed on Linux). -- Pino Toscano signature.asc Description: This is a digitally signed message part. ___ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs
Re: [Libguestfs] [PATCH v6 05/41] utils: Split out cleanups into common/cleanups.
On Fri, Jun 16, 2017 at 03:24:55PM +0200, Pino Toscano wrote: > On Thursday, 15 June 2017 19:05:55 CEST Richard W.M. Jones wrote: > > Those cleanups which only depend on libc, gnulib or libxml2 are split > > out into a separate common/cleanups directory. > > --- > > IMHO a single cleanups.c source should be enough, otherwise it's overly > split... I think you do need to split it. The reason is that if the program uses libcleanups.la but doesn't link to (eg) libxml2 then the link will fail. We could either force everything to link unnecessarily to libxml2 or we can split the object files so that the libxml2 dependency is never pulled in if the main program doesn't use it. And the same applies (but a bit less) to gnulib. I'm not sure anything doesn't link to gnulib though, and probably everything should (except examples but they don't use cleanups). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs
Re: [Libguestfs] [PATCH v6 05/41] utils: Split out cleanups into common/cleanups.
On Thursday, 15 June 2017 19:05:55 CEST Richard W.M. Jones wrote: > Those cleanups which only depend on libc, gnulib or libxml2 are split > out into a separate common/cleanups directory. > --- IMHO a single cleanups.c source should be enough, otherwise it's overly split... -- Pino Toscano signature.asc Description: This is a digitally signed message part. ___ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs
