I'm getting this runtime error:

$ nix-build -A eagle
/nix/store/z8pm3csczwy830z16qzrqg3igcs5ql9z-eagle-9.1.2
$ ./result/bin/eagle 
terminate called after throwing an instance of 'std::runtime_error'
  what():  locale::facet::_S_create_c_locale name not valid
Aborted

Tried with LANG=C (wild guess) but didn't change anything.

I got the same error when I tried to build eagle with nixpkg from Github like:

nix-shell -Inixpkgs=$PATH_TO_NIXPKGS_MASTER -p eagle

Using this instead fixed it for me (in the eagle directory):

nix-build -E 'with import <nixpkgs> { }; libsForQt5.callPackage ./eagle.nix {}'

My guess was that you mix incompatible glibc versions (see #38991): master seems to be at 2.27, stable (on my machines) on 2.26.
This is not an eagle issue and can be worked around by using the packages from stable to build eagle (the nix-build command from above).

EDIT: I'll appy the suggestion of @volth later today, so please don't merge this, yet ;) .

Okay, I think I applied the suggestion of @volth.
Is there a way to notify the users of this package that the old version is still available as eagle7?
Eagle is unable to open example projects, working on my own projects works though.
Maybe I'll find a fix later, but this should be a minor issue (maybe it is a good idea to also create an issue here for documentation purposes?).

Why would you still keep the old version?

I believe eagle >= 8.x requires an account and a subscription to use it. Older version is something you buy and own yourself.

The old version is still functional, but I have not tried, to run both versions at the same time.
Eagle versions ≥8.0 require an Autodesk account and the pricing changed from single payment to subscription like @bjornfor said.
I assumed that either people are not upgrading deliberately (like @bjornfor maybe?) or that it is not really used on Nix.
I personally don't mind dropping Eagle 7, but I am aware of the controversy the change caused.
I'm going to add a comment later today.

If it was not upgraded because of lack of maintenance adding more versions is not a good idea.

I'm not an active eagle user (never was), but I would like to keep the 7.x version around for the single reason that it can be run without subscription. I didn't update/add eagle >= 8.x due to lack of time/interest and dislike of the new subscription model. See my original reasoning in 28f780b.

Ok. @rittelle please add an explanation why we keep 7.x around.

@Mic92 like this?
I'd appreciate corrections if it contains spelling or grammar errors.
@bjornfor I removed you from the maintainer list of Eagle 9 based on your responses above (the lack of interest), so you are not listed as a maintainer for a package you never used.

I'm still getting that fatal startup error:

  what():  locale::facet::_S_create_c_locale name not valid
Aborted

Wasn't that fixed? I'm on NixOS 18.03.

How do you build and run the application?
Have you seen how I got it running on my system (also 18.03 stable) and my guess why it is not working in a comment above (here)?

I do do not have that problem with nix-review pr 44951. @bjornfor can you reproduce the problem there?

@rittelle: I build and run with git checkout origin/pr/44951 && nix-build -A eagle && ./result/bin/eagle.

Using nix-build -E 'with import <nixpkgs> { }; libsForQt5.callPackage ./eagle.nix {}' is not reproducible since <nixpkgs> resolves to different things depending on what's in $NIX_PATH (different glibc, qt etc.). When I'm on NixOS 18.03 it works. When I switch to unstable/master it fails, in the same way as running nix-build -A eagle && ./result/bin/eagle in the nixpkgs tree.

@Mic92: Yes, I still get the problem when using nix-review pr 44951 and invoking eagle in its nix-shell. How weird that we get different result.

I found what's wrong. The $LOCALE_ARCHIVE on NixOS 18.03 is incompatible (EDIT: too old -> incompatible). It works when the application is wrapped with LOCALE_ARCHIVE=${glibcLocales}/lib/locale/locale-archive when ${glibcLocales} is from master.

It appears $LOCALE_ARCHIVE is set globally on NixOS. I don't know if there is a policy against wrapping applications with $LOCALE_ARCHIVE, but in this case it would definitely fix an impurity.

This looks to me, like something that should be rather solved in stdenv, then in every package.