Message ID | 255977954.4763389.1390820376074.JavaMail.root@openwide.fr |
---|---|
State | Rejected |
Headers | show |
Hi Romain, Kirill, On 01/27/2014 12:59 PM, Romain Naour wrote: > I had the same problem with infozip and I fixed this error by patching unix/Makefile like this: (...) > match.o: match.S > $(CPP) match.S > _match.s > - $(AS) _match.s > - mv _match.o match.o > - rm -f _match.s > + $(AS) _match.s -o match.o (...) > (Ok, this patch is really weird...) Why? To me it seems that $(AS) should not be expected to output by default to <basename>.o, as is apparently expected in the infozip's unix/Makefile. GNU as outputs to a.out by default. If I build the package in my host environment, it picks "$(CC) -c" as the value for $(AS) and works OK but when called from Buildroot, the value for $(AS) is set to invoke the toolchain's as directly, and the output of it goes to a.out. Am I totally wrong in believing that your patch is the right way to produce match.o rather than original way of doing it? -- Best regards, Alexander Lukichev
Hi Alexander, ----- Mail original ----- | De: "Alexander Lukichev" <alexander.lukichev@gmail.com> | À: "Romain Naour" <romain.naour@openwide.fr> | Cc: "Кирилл Луценко" <lucenko_kirill@mail.ru>, buildroot@busybox.net | Envoyé: Lundi 27 Janvier 2014 12:47:49 | Objet: Re: [Buildroot] i686-buildroot-linux-gnu-as does not work | | Hi Romain, Kirill, | | On 01/27/2014 12:59 PM, Romain Naour wrote: | > I had the same problem with infozip and I fixed this error by | > patching unix/Makefile like this: | (...) | > match.o: match.S | > $(CPP) match.S > _match.s | > - $(AS) _match.s | > - mv _match.o match.o | > - rm -f _match.s | > + $(AS) _match.s -o match.o | (...) | > (Ok, this patch is really weird...) | Why? | | To me it seems that $(AS) should not be expected to output by default | to <basename>.o, as is | apparently expected in the infozip's unix/Makefile. GNU as outputs to | a.out by default. | | If I build the package in my host environment, it picks "$(CC) -c" as | the value for $(AS) and | works OK but when called from Buildroot, the value for $(AS) is set | to invoke the toolchain's | as directly, and the output of it goes to a.out. | | Am I totally wrong in believing that your patch is the right way to | produce match.o rather | than original way of doing it? Sorry, I meant that usually in buildroot, Makefile's variables are overwritten in foo.mk I removed my patch and added AS="$(TARGET_CC) -c" in infozip.mk $(MAKE) $(TARGET_CONFIGURE_OPTS) -C $(@D) AS="$(TARGET_CC) -c" -f unix/Makefile generic infozip compiles fine by doing that. Best regards, Romain Naour | | -- | Best regards, | Alexander Lukichev |
On 27/01/14 13:48, Romain Naour wrote: > I meant that usually in buildroot, Makefile's variables are overwritten in foo.mk > > I removed my patch and added AS="$(TARGET_CC) -c" in infozip.mk > > $(MAKE) $(TARGET_CONFIGURE_OPTS) -C $(@D) AS="$(TARGET_CC) -c" -f unix/Makefile generic > > infozip compiles fine by doing that. Actually there's a deeper cause I'm afraid... The make command calls unix/configure to find out some things about the platform, but the configure script sets CPP to /usr/bin/cpp or /lib/cpp if either of these exist. But those host tools obviously have the wrong predefined symbols, so the configure script will test if it is possible to use assembly for the host, not for the target... I think there are two possible "right" solutions: 1. fix unix/configure; 2. bypass unix/configure by using the generic_gcc target instead. Regards, Arnout
Hi Arnout, Le 27/01/2014 23:23, Arnout Vandecappelle a écrit : > On 27/01/14 13:48, Romain Naour wrote: >> I meant that usually in buildroot, Makefile's variables are >> overwritten in foo.mk >> >> I removed my patch and added AS="$(TARGET_CC) -c" in infozip.mk >> >> $(MAKE) $(TARGET_CONFIGURE_OPTS) -C $(@D) AS="$(TARGET_CC) -c" -f >> unix/Makefile generic >> >> infozip compiles fine by doing that. > > Actually there's a deeper cause I'm afraid... > > The make command calls unix/configure to find out some things about > the platform, but the configure script sets CPP to /usr/bin/cpp or > /lib/cpp if either of these exist. But those host tools obviously have > the wrong predefined symbols, so the configure script will test if it > is possible to use assembly for the host, not for the target... > > I think there are two possible "right" solutions: > > 1. fix unix/configure; > 2. bypass unix/configure by using the generic_gcc target instead. > > Regards, > Arnout > Thanks, that's why I had two situations: At work, I use an i386 system then the test "Check if we can use asm code" pass and build fail with: output/host/usr/bin/i686-buildroot-linux-gnu-as _crc_i386.s mv _crc_i386.o crc_i386.o mv: mv _match.o match.o cannot stat `_crc_i386.o': No such file or directory At home, I use an x86_64 then the test fail thus there is no build error... I have send a patch series to fix build issues with infozip package. Best regards, Romain Naour
diff --git a/unix/Makefile b/unix/Makefile index abd0c44..fc8166f 100644 --- a/unix/Makefile +++ b/unix/Makefile @@ -103,15 +103,11 @@ zipup.o: unix/zipup.h match.o: match.S $(CPP) match.S > _match.s - $(AS) _match.s - mv _match.o match.o - rm -f _match.s + $(AS) _match.s -o match.o crc_i386.o: crc_i386.S $(CPP) crc_i386.S > _crc_i386.s - $(AS) _crc_i386.s - mv _crc_i386.o crc_i386.o - rm -f _crc_i386.s + $(AS) _crc_i386.s -o crc_i386.o unix.o: unix/unix.c $(CC) -c $(CFLAGS) unix/unix.c
Hi K irill , I had the same problem with infozip and I fixed this error by patching unix/Makefile like this: From: Romain Naour < romain.naour@openwide.fr > Date: Fri, 31 May 2013 14:39:18 +0200 Subject: [PATCH 1/1] Fix Makefile --- unix/Makefile | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-)