Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

./compile.sh: line 355: third_party/protobuf/protoc.amd64: cannot execute binary file: Exec format error #18

Closed
filmil opened this issue Mar 24, 2015 · 9 comments
Closed

./compile.sh: line 355: third_party/protobuf/protoc.amd64: cannot execute binary file: Exec format error #18

filmil opened this issue Mar 24, 2015 · 9 comments
Labels
P2 We'll consider working on this in future. (Assignee optional) type: bug

Comments

@filmil
Copy link

filmil commented Mar 24, 2015

This is what I get when trying to compile Bazel on my machine.

$ ./compile.sh
Compiling Java stubs for protocol buffers...
./compile.sh: line 355: third_party/protobuf/protoc.amd64: cannot execute binary file: Exec format error

My machine says:
$ uname -a
Linux cowfarm 3.13.0-34-generic #60-Ubuntu SMP Wed Aug 13 15:49:09 UTC 2014 i686 i686 i686 GNU/Linux

I'm guessing all the cool kids run AMD these days. :)
@hanwen
Copy link
Contributor

hanwen commented Mar 24, 2015

yeah. It'll probably work if you replace it with a binary that executes correctly on your machine (it should be from protobuf 2.5.0).

@filmil
Copy link
Author

filmil commented Mar 25, 2015

Is there any special reason that i686 binaries aren't there? Is it even
worth running bazel on a 32-bit machine?

On Tue, Mar 24, 2015 at 12:20 PM Han-Wen Nienhuys [email protected]
wrote:

yeah. It'll probably work if you replace it with a binary that executes
correctly on your machine (it should be from protobuf 2.5.0).

—
Reply to this email directly or view it on GitHub
#18 (comment).

@hanwen
Copy link
Contributor

hanwen commented Mar 25, 2015

No special reason, we just forgot about i686.

@damienmg damienmg added type: bug P2 We'll consider working on this in future. (Assignee optional) labels Mar 26, 2015
@MarkRunWu
Copy link

I tried to replace by 32 bit version protoc.
It still cannot be built cause the codebase is targeted at 64 bit machine. 😖

src/main/cpp/blaze.cc: In function ‘void blaze::ActuallyExtractData(const string&, const string&)’:
src/main/cpp/blaze.cc:804:71: error: cannot convert ‘off_t* {aka long int*}’ to ‘int64_t* {aka long long int*}’ for argument ‘4’ to ‘int archive_read_data_block(archive*, const void**, size_t*, int64_t*)’
       retval = archive_read_data_block(blaze_zip, &buf, &size, &offset);
                                                                       ^

@damienmg
Copy link
Contributor

Sorry we have to work that out. We are setting up external CI systems and we might able to target 32bits.

@srib
Copy link

srib commented Apr 7, 2015

Any idea when a fix to this might be pushed for i686?

@damienmg
Copy link
Contributor

damienmg commented Apr 8, 2015

Hanwen: can you take care of this one?
Also you might want to see with Kristina if we can set-up 32-bit build on Travis

@srib
Copy link

srib commented Apr 9, 2015

Hanwen: thanks for fixing this problem!

@kchodorow
Copy link
Contributor

Whoops, didn't mean to close. Not sure if 32-bit compile actually works now, but there is a 32-bit protoc in https://github.com/google/bazel/tree/master/third_party/protobuf now.

@kchodorow kchodorow reopened this Apr 9, 2015
@ulfjack ulfjack closed this as completed Apr 10, 2015
hanwen added a commit that referenced this issue Apr 13, 2015
@hanwen @lberki
Use int64_t for the offset argument of libarchive function call.
8d676c5 
off_t and int64_t are different on 32-bit platforms.

Fixes #18.

--
MOS_MIGRATED_REVID=90802730
@damienmg damienmg mentioned this issue Apr 13, 2015
Closed
bazel-io pushed a commit that referenced this issue Mar 18, 2019
@Quarz0 @copybara-github
Extend dict update to accept keyword args
b37296c 
Closes [dict.update should return None, not self #18](bazelbuild/starlark#18)

dict.update() method should now accept keyword args just like dict(...)

**Example of usage:**
```
>> a = dict(a=1)
..
>> a.update(b=2)
..
None
>> a.update({'c': 3})
..
None
>> a
..
{"a": 1, "b": 2, "c": 3}
```

Closes #7684.

PiperOrigin-RevId: 239018051
tomaszstrejczek pushed a commit to tomaszstrejczek/bazel that referenced this issue Oct 20, 2019
@pcj @zaphar
Adds new_nuget_package (bazelbuild#27)
f8950cb 
* - Adds new_http_archive for nuget-binary from github commit zipfile.
- Adds label attributes to nuget_package rule to get mono and nuget binary paths.
- Checks return value of execute nuget_cmd and fails with non-zero value.
- Changes dll_import rule in nuget_package BUILD from
  `@workspace_name//:workspace_name` to `@workspace_name//:dylibs`
  (less redundant, more descriptive).
- Bumps README.md to 0.0.3.

* - Adds new_nuget_package as workaround for Issue bazelbuild#18.
- csharp_binary fixes for path outputs. Closes bazelbuild#26.

* Reverts attr dict addition to maintain syntax conformance with python.

* Documentation for new_nuget_package.
Closed
@rock626 rock626 mentioned this issue Apr 29, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
P2 We'll consider working on this in future. (Assignee optional) type: bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@kchodorow @hanwen @filmil @MarkRunWu @damienmg @ulfjack @srib