Skip to content
This repository has been archived by the owner on Dec 15, 2022. It is now read-only.

Build Fails on FreeBSD Error: incorrect header check at Zlib #282

Closed
mike-pt opened this issue Feb 2, 2015 · 10 comments
Closed

Build Fails on FreeBSD Error: incorrect header check at Zlib #282

mike-pt opened this issue Feb 2, 2015 · 10 comments
Labels

Comments

@mike-pt
Copy link

mike-pt commented Feb 2, 2015

node ./script/download-node.js

events.js:72
throw er; // Unhandled 'error' event
^
Error: incorrect header check
at Zlib._binding.onerror (zlib.js:296:17)

@mike-pt
Copy link
Author

mike-pt commented Feb 11, 2015

Any idea how to fix/work around it?

@pusateri
Copy link
Contributor

This throw er; turns out to be the fact that apm is trying to download a binary package of node to run and freebsd isn't in the list of built packages.

http://nodejs.org/dist/v0.10.35/

% node ./script/download-node.js
It wants http://nodejs.org/dist/v0.10.35/node-v0.10.35-freebsd-x64.tar.gz

If we are building from source, maybe we can just skip this install step and use the native node.

@kevinsawicki
Copy link
Contributor

Closed by #360

@mike-pt
Copy link
Author

mike-pt commented May 8, 2015

This doesn't fix the issue completely for freebsd, it simply help understand better what happens (404 downloading node).

In practice the zlib issue is gone but compilation still fails for freebsd, and node is already installed anyway, if node is installed why even try to download it again?

If the error is 404 but node is installed apm build should proceed.

@mike-pt
Copy link
Author

mike-pt commented May 8, 2015

Sorry for the spam, but I was looking at the what the ports are getting as a distfile, and it seems its "node-v0.xx.x.tar.gz", so maybe a good way to handle it would be to just check if its freebsd and download the tar.gz

So basically if its "freebsd" remove "process.platform" (edit: and arch too), I could make a PR for that change if it sounds reasonable?

@pusateri
Copy link
Contributor

pusateri commented May 8, 2015

Yes, this is a baby step. It keeps it from throwing an exception. I hope we can make it fall back to the native version. In the mean time, use this patch:
https://gist.github.com/pusateri/a5283313fdbef9922ce6#file-package-json-diff

@mike-pt
Copy link
Author

mike-pt commented May 8, 2015

Sounds ok, I'm my case I had to use ln -s instead of creating a hard link but this is a nice workaround for now.

@pusateri
Copy link
Contributor

pusateri commented May 8, 2015

Yeah, mine is one big ZFS tank. I'll change that diff to use a symbolic link.
After building apm, checkout atom and apply this patch:
https://gist.github.com/pusateri/eb98a25e3ae45309aed7#file-freebsd-atom-diff

This will point atom at the patched apm.
minidump is for creating crash dumps. We can live without it for now.
And 'rm build/tasks/dump-symbols-task.coffee' for now.

@mike-pt
Copy link
Author

mike-pt commented May 8, 2015

Ok, will try that now, btw bin/apm is using the /bin/bash shebang... probably best to use "#!/usr/bin/env bash"

as not all os have bash in the same place, and in freebsd its installed to /usr/local/bin so it would fail.

*EDIT: same for atom.sh

@pusateri
Copy link
Contributor

pusateri commented May 8, 2015

Yes, using env is good practice.
apm install doesn't seem to be doing anything:
[pusateri@dark ~/src/atom/apm]$ ../../apm/bin/apm install

but dedupe seems happy:
[pusateri@dark ~/src/atom/apm]$ ../../apm/bin/apm dedupe
Deduping modules ✓

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants