Sometimes, when you least expect it, a static binary is what you need to rescue your data... Or just get a good enough handle on things to make it work again ;) "make static" is a gift to you, dear user with filesystem problems! --- Makefile | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/Makefile b/Makefile index 4894903..9148d0b 100644 --- a/Makefile +++ b/Makefile @@ -117,4 +117,8 @@ install: $(progs) install-man $(INSTALL) -m755 -d $(DESTDIR)$(bindir) $(INSTALL) $(progs) $(DESTDIR)$(bindir) +static: CFLAGS += -static +static: LIBS += -lpthread +static: all + -include .*.d -- 1.8.1.1 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/25/2013 07:09 PM, Ian Kumlien wrote:> Sometimes, when you least expect it, a static binary is what you need to > rescue your data... Or just get a good enough handle on things to make > it work again ;)You certainly have a good point. I took q quick look on Fedora 18 and e2fsprogs has a separate static package but xfsprogs, jfsutils, and reiserfs-utils do not. On the other hand, those without a separate static package may be only static. I guess it depends how much bloat there would be with static only. For e2fsprogs, the static package only contains the static (".a") libraries. I believe your patch makes all of the binaries static linked. Is this necessary? 1) Btrfs fixes a lot of stuff on-the fly. 2) If you need to recover "standalone", rescue has btrfs. I did a quick check and most of the btrfs binaries are less than 200K bytes whereas the static versions are around 1.2M bytes. I know that disk space is cheap these days but does this solve a real problem? Gene> > "make static" is a gift to you, dear user with filesystem problems! > --- > Makefile | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/Makefile b/Makefile > index 4894903..9148d0b 100644 > --- a/Makefile > +++ b/Makefile > @@ -117,4 +117,8 @@ install: $(progs) install-man > $(INSTALL) -m755 -d $(DESTDIR)$(bindir) > $(INSTALL) $(progs) $(DESTDIR)$(bindir) > > +static: CFLAGS += -static > +static: LIBS += -lpthread > +static: all > + > -include .*.d-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Jan 27, 2013 at 12:11:37PM -0500, Gene Czarcinski wrote:> On 01/25/2013 07:09 PM, Ian Kumlien wrote: > > Sometimes, when you least expect it, a static binary is what you need to > > rescue your data... Or just get a good enough handle on things to make > > it work again ;) > You certainly have a good point. I took q quick look on Fedora 18 and > e2fsprogs has a separate static package but xfsprogs, jfsutils, and > reiserfs-utils do not. On the other hand, those without a separate > static package may be only static. > > I guess it depends how much bloat there would be with static only. For > e2fsprogs, the static package only contains the static (".a") > libraries. I believe your patch makes all of the binaries static linked.Yes, ''btrfs'' is my main goal> Is this necessary? 1) Btrfs fixes a lot of stuff on-the fly. 2) If you > need to recover "standalone", rescue has btrfs.I have needed this on several ocations, f.ex. running a ubuntu livecd on one machine to try to fix something - compiling it on another machine and then copying it and running it on the affected machine. In some cases this has been to get a hold of a specific version of btrfs-progs> I did a quick check and most of the btrfs binaries are less than 200K > bytes whereas the static versions are around 1.2M bytes. I know that > disk space is cheap these days but does this solve a real problem?Non stripped btrfs here is 2.4 MB, stripped 1.1 MB - this is 64 bit gcc 4.7.2. My patch adds a compile target to allow you to build static binaries, it''s something i have manually hardcoded in to various btrfs-progs.> Gene > > > > "make static" is a gift to you, dear user with filesystem problems! > > --- > > Makefile | 4 ++++ > > 1 file changed, 4 insertions(+) > > > > diff --git a/Makefile b/Makefile > > index 4894903..9148d0b 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -117,4 +117,8 @@ install: $(progs) install-man > > $(INSTALL) -m755 -d $(DESTDIR)$(bindir) > > $(INSTALL) $(progs) $(DESTDIR)$(bindir) > > > > +static: CFLAGS += -static > > +static: LIBS += -lpthread > > +static: all > > + > > -include .*.d >-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Jan 26, 2013 at 01:09:47AM +0100, Ian Kumlien wrote:> Sometimes, when you least expect it, a static binary is what you need to > rescue your data... Or just get a good enough handle on things to make > it work again ;) > > "make static" is a gift to you, dear user with filesystem problems!Adding the build target does not cost us anything. The result depends on the distro and set of the needed libraries provided for a static build. Even the basic ''btrfs'' too needs uuid (due to cmds-receive) and I don''t have it in my distro. The other utilities may need static zlib or lzo (restore) or libblkid (mkfs.btrfs). I tried to build ''btrfs'' only and moved the static libs definition to the beginning (still needs the uuid static library though): --- a/Makefile +++ b/Makefile @@ -19,6 +19,7 @@ prefix ?= /usr/local bindir = $(prefix)/bin LIBS=-luuid -lm RESTORE_LIBS=-lz +STATIC_LIBS= -lpthread progs = btrfsctl mkfs.btrfs btrfs-debug-tree btrfs-show btrfs-vol btrfsck \ btrfs btrfs-map-logical btrfs-image btrfs-zero-log btrfs-convert \ @@ -117,4 +118,9 @@ install: $(progs) install-man $(INSTALL) -m755 -d $(DESTDIR)$(bindir) $(INSTALL) $(progs) $(DESTDIR)$(bindir) +static: CFLAGS += -static +static: LIBS = $(STATIC_LIBS) +static: version btrfs -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jan 28, 2013 at 06:05:00PM +0100, David Sterba wrote:> On Sat, Jan 26, 2013 at 01:09:47AM +0100, Ian Kumlien wrote: > > Sometimes, when you least expect it, a static binary is what you need to > > rescue your data... Or just get a good enough handle on things to make > > it work again ;) > > > > "make static" is a gift to you, dear user with filesystem problems! > > Adding the build target does not cost us anything. The result depends on the > distro and set of the needed libraries provided for a static build. Even > the basic ''btrfs'' too needs uuid (due to cmds-receive) and I don''t have > it in my distro. The other utilities may need static zlib or lzo > (restore) or libblkid (mkfs.btrfs).Yes, this is all part of the static package...> I tried to build ''btrfs'' only and moved the static libs definition to > the beginning (still needs the uuid static library though):Which you haven''t included - you sould also include btrfsck at bare minimum ;)> --- a/Makefile > +++ b/Makefile > @@ -19,6 +19,7 @@ prefix ?= /usr/local > bindir = $(prefix)/bin > LIBS=-luuid -lm > RESTORE_LIBS=-lz > +STATIC_LIBS= -lpthread > > progs = btrfsctl mkfs.btrfs btrfs-debug-tree btrfs-show btrfs-vol btrfsck \ > btrfs btrfs-map-logical btrfs-image btrfs-zero-log btrfs-convert \ > @@ -117,4 +118,9 @@ install: $(progs) install-man > $(INSTALL) -m755 -d $(DESTDIR)$(bindir) > $(INSTALL) $(progs) $(DESTDIR)$(bindir) > > +static: CFLAGS += -static > +static: LIBS = $(STATIC_LIBS)I think you mean += since this will not build since it misses libuuid If you don''t have the libs to do a static build - that is one thing but it should work =)> +static: version btrfs-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jan 28, 2013 at 07:41:01PM +0100, Ian Kumlien wrote:> > I tried to build ''btrfs'' only and moved the static libs definition to > > the beginning (still needs the uuid static library though): > > Which you haven''t included - you sould also include btrfsck at bare > minimum ;) > > > --- a/Makefile > > +++ b/Makefile > > @@ -19,6 +19,7 @@ prefix ?= /usr/local > > +STATIC_LIBS= -lpthread > > +static: CFLAGS += -static > > +static: LIBS = $(STATIC_LIBS) > > I think you mean += since this will not build since it misses libuuid > > If you don''t have the libs to do a static build - that is one thing but > it should work =)Resume: if the distro contains all required libs as static, then your patch works. I wanted to get an idea how the static build would go so my patch was a dirty workaroud, that did not work in the end anyway. david -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jan 28, 2013 at 10:46:51PM +0100, David Sterba wrote:> On Mon, Jan 28, 2013 at 07:41:01PM +0100, Ian Kumlien wrote: > > > I tried to build ''btrfs'' only and moved the static libs definition to > > > the beginning (still needs the uuid static library though): > > > > Which you haven''t included - you sould also include btrfsck at bare > > minimum ;) > > > > > --- a/Makefile > > > +++ b/Makefile > > > @@ -19,6 +19,7 @@ prefix ?= /usr/local > > > +STATIC_LIBS= -lpthread > > > +static: CFLAGS += -static > > > +static: LIBS = $(STATIC_LIBS) > > > > I think you mean += since this will not build since it misses libuuid > > > > If you don''t have the libs to do a static build - that is one thing but > > it should work =) > > Resume: if the distro contains all required libs as static, then your > patch works.Yeah... But if it''s shipped in a dist i assume they will create static versions and srip them, just like it seems that other dists does.> I wanted to get an idea how the static build would go so my patch > was a dirty workaroud, that did not work in the end anyway.=) I was a bit confused about it - but you are right, ''btrfs'' and ''btrfsck'' is the only two we really need to have as static...> david-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jan 28, 2013 at 10:46:51PM +0100, David Sterba wrote:> Resume: if the distro contains all required libs as static, then your > patch works. > > I wanted to get an idea how the static build would go so my patch > was a dirty workaroud, that did not work in the end anyway.To reiterate: ldd btrfs btrfsck btrfs: not a dynamic executable btrfsck: not a dynamic executable du -sh btrfs btrfsck 2,4M btrfs 2,1M btrfsck strip btrfs strip btrfsck du -sh btrfs btrfsck 1,1M btrfs 904K btrfsck --- And now dynamic: du -sh btrfs btrfsck 1,5M btrfs 1,3M btrfsck strip btrfsck ; strip btrfs du -sh btrfs btrfsck 232K btrfs 156K btrfsck --- This means that dists are striping binaries... In which case it would be no problem to have then build the static target, perhaps we could try to verify if they are available and build btrfs.static and btrfsck.static if possible.... (I''m using: 64 bit - gcc 4.7.2) -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jan 29, 2013 at 12:31:53AM +0100, Ian Kumlien wrote:> This means that dists are striping binaries... > In which case it would be no problem to have then build the static target, > perhaps we could try to verify if they are available and build btrfs.static > and btrfsck.static if possible....I like that, keeping the .static versions along the dynamic ones, just for the rescue purposes. (And to reduce the total file size even further merge the fsck functionlity into ''btrfs'', but this is not a primary goal now.) david -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html