Package Details: eagle 9.6.2-1

Git Clone URL: (read-only, click to copy)
Package Base: eagle
Description: Powerful suite for schematic capture and printed circuit board design (aka eaglecad)
Upstream URL:
Licenses: custom
Submitter: None
Maintainer: Bevan
Last Packager: Bevan
Votes: 281
Popularity: 0.190959
First Submitted: 2008-03-24 12:05 (UTC)
Last Updated: 2020-06-08 14:46 (UTC)

Pinned Comments

Latest Comments

vglinden commented on 2021-09-07 16:54 (UTC)

Thank you!

Bevan commented on 2021-09-07 08:26 (UTC)

@vglinden: It should be under ~/.local/share/Eagle/settings/9.6.2/eaglerc. Note that this path changes with each eagle update.

vglinden commented on 2021-09-07 05:51 (UTC)

This package works very well for me. But I can't find the eaglerc, even although it hold configurations I make. Would anyone care to tell me where it is please?

Limhes commented on 2021-05-17 06:33 (UTC) (edited on 2021-05-17 06:42 (UTC) by Limhes)

@Bevan: Removing the variable as you suggest leads to the same behavior. On my system LD_LIBRARY_PATH is set to /usr/local/MATLAB/MATLAB_Runtime/v910/runtime/glnxa64:/usr/local/MATLAB/MATLAB_Runtime/v910/bin/glnxa64:/usr/local/MATLAB/MATLAB_Runtime/v910/sys/os/glnxa64:/usr/local/MATLAB/MATLAB_Runtime/v910/extern/bin/glnxa64

PS: Running e.g. kde-open5 from a terminal works just fine

PS2: Running /opt/eagle/eagle from a terminal also works fine, and opens web pages correctly after clicking "view on web". Am I using my system's Qt version here instead of Eagle's supplied Qt?

Bevan commented on 2021-05-14 12:39 (UTC)

@Limhes: This looks it's caused by our custom start script that sets LD_LIBRARY_PATH. Do you normally have that variable set to anything?

Could you please try the following?

env -u LD_LIBRARY_PATH eagle

Limhes commented on 2021-05-14 12:22 (UTC)

Eagle works fine, but when I try to "view on web" on a managed library or a 3D model, nothing happens and console shows this:

kde-open5: /opt/eagle/lib/ version `Qt_5.15' not found (required by kde-open5)
kde-open5: /opt/eagle/lib/ version `Qt_5.15' not found (required by /usr/lib/
(... 21 more similar lines...)
kde-open5: /opt/eagle/lib/ version `Qt_5.15' not found (required by /usr/lib/

I just rebuilt & installed the AUR package, my qt5-base version is 5.15.2+kde+r192-1. Running eagle with LD_LIBRARY_PATH=(any lib path here):$LD_LIBRARY_PATH /usr/bin/eagle does not solve the problem.

JohnRobson commented on 2019-11-25 23:16 (UTC)

@Bevan worked!!! thank you so much.

Bevan commented on 2019-11-24 19:14 (UTC) (edited on 2019-11-24 19:15 (UTC) by Bevan)

@JohnRobson: Your problem looks quite similar to that one of rpash. Could you please try to run eagle as follows?

LD_LIBRARY_PATH=/opt/eagle/lib:$LD_LIBRARY_PATH /usr/bin/eagle

JohnRobson commented on 2019-11-23 22:13 (UTC)

Someone can help me with this error?

$ /usr/bin/eagle
Qt: Session management error: Could not open network socket
Sandboxing disabled by user.
/opt/eagle/libexec/QtWebEngineProcess --type=zygote --no-sandbox --webengine-schemes=qrc:sLV --lang=en-US: symbol lookup error: /opt/eagle/libexec/QtWebEngineProcess --type=zygote --no-sandbox --webengine-schemes=qrc:sLV --lang=en-US: undefined symbol: _ZN7content20localtime_r_overrideEPKlP2tm, version Qt_5
[3633:3633:1123/171126.525791:ERROR:extension_system_qt.cpp(123)] Failed to parse extension manifest.
Segmentation fault (core dumped)

Bevan commented on 2019-11-17 19:59 (UTC)

Thanks for reporting the cause. Maybe we should replace the link under /usr/bin/eagle by a small wrapper script that makes sure that LD_LIBRARY_PATH is not excluding those provided libraries.

rpash commented on 2019-11-17 19:48 (UTC) (edited on 2019-11-17 19:49 (UTC) by rpash)

@Bevan: It seems that all QT related libraries are provided by /lib not /opt/eagle/lib, though they exist in both. I added /opt/eagle/lib to LD_LIBRARY_PATH and that fixed the issue. Seems it didn't break because of the update but because I actually created a LD_LIBRARY_PATH variable around the same time. Thanks for the tip!

Bevan commented on 2019-11-14 10:46 (UTC) (edited on 2019-11-14 11:48 (UTC) by Bevan)

@rpash: I quickly tried and cannot reproduce your problem. Please run the following command:

ldd /opt/eagle/lib/

You should see that all qt related libraries are those provided by eagle. If not, please post the output here.

The symbol that is not found in your case is defined in /opt/eagle/lib/ So especially look out for that line.

rpash commented on 2019-11-14 01:21 (UTC)

As of the Juhraya update to Manjaro, eagle gives the following error:

symbol lookup error: /opt/eagle/lib/ undefined symbol: _ZSt24__throw_out_of_range_fmtPKcz, version Qt_5

I am not sure where that symbol is supposed to be, I have tried reverting all my QT packages to the versions pre-update among other things, but the issue persists. Any idea of where I could look to resolve this issue?

Bevan commented on 2019-05-21 13:16 (UTC)

Good enough :-) Typically, these minor updates are relatively painless. Thanks!

jaskij commented on 2019-05-21 13:14 (UTC)

@Bevan: if three months without updates didn't break my personal system I'll do it in the evening. Is Manjaro fine?

Bevan commented on 2019-05-21 12:45 (UTC) (edited on 2019-05-21 12:47 (UTC) by Bevan)

@jaskij: Unfortunately, my Arch system is currently not available for me to test the new version. I pushed a new PKGBUILD to Could you test if this works for you? If yes, I'll push it here.

jaskij commented on 2019-05-21 12:35 (UTC)

@gunjah @Bevan there is a known issue with Eagle crashing after updating the assembly variant. It is partially fixed in 9.4.1 which is already released.

See this thread:

Bevan commented on 2019-04-15 07:41 (UTC)

@gunjah, there were no major changes to this PKGBUILD since 9.1.1 so I would expect it to work. However, I assume it is pretty much untested on a recent Arch Linux. Is there a specific reason you cannot use the most recent version of Eagle?

Or does anybody have crashes with the current version as well?

coldspark commented on 2019-04-15 07:25 (UTC) (edited on 2019-04-15 07:27 (UTC) by coldspark)

EAGLE crashes regularly. Might this be because I used this script with version 9.1.1 of the tarball?

renne commented on 2018-07-14 08:04 (UTC)

The ULP plug-in provides access to the Componentsearchengine components database.

Please add it to the EAGLE packages.

kimani commented on 2018-07-04 20:09 (UTC)

New update from

Logged in and update button came up.

Bevan commented on 2018-06-12 18:19 (UTC)

Thanks for the report! I don't use eagle on a daily basis so I wasn't aware of this issue yet. I just pushed a version that should fix this issue. Please report if you notice any remaining or new issues.

sotoleni commented on 2018-06-12 09:49 (UTC)

You have to downgrade the "mesa" package to the last version: 18.0.4-1 The newer version 18.1.1-1 produce that output. I don't know who is generating the problem, eagle or mesa?

goodmen commented on 2018-06-12 09:12 (UTC)

I got something wrong:

Could not initialize GLX Aborted (core dumped)

Bevan commented on 2018-03-06 21:35 (UTC)

randusr: Thanks for the hint on the update button within eagle. Since I did not have such a button anywhere in the UI (and in fact never have seen it before), I experimented around a bit. It seems like you only get the update message when you log in with your Autodesk account.

randusr commented on 2018-03-06 13:57 (UTC)

There is a new version at You are redirected there from within eagle when you klick the Update button.

I did not try it yet, just wanted to let you know.

dpello commented on 2018-02-21 08:16 (UTC) (edited on 2018-02-21 08:18 (UTC) by dpello)

Last version fails to work with this message:

% eagle

terminate called after throwing an instance of 'std::runtime_error'

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

[1] 28911 abort (core dumped) eagle

It's solved if you install en_US.UTF-8 locale.

Bevan commented on 2017-08-29 08:33 (UTC)

sotoleni: Good catch, thanks!

sotoleni commented on 2017-08-28 08:49 (UTC)

In the folder: /opt/eagle/lib There is two files: lrwxrwxrwx 1 root root 27 2017-08-28 09:19 -> /opt/eagle/lib/ -rw-r--r-- 1 root root 401K 2017-08-14 22:41 The symbolic link have to be modified to target: "" and not "" It makes to fail the SSL connection to be registered with Autodesk Thank you very much to support this package, you do a great job! Toni

Bevan commented on 2017-08-04 19:07 (UTC)

@z3bu: Thanks for the hint! namcap confirms this is a dependency which I must have missed... I will push a new version.

z3bu commented on 2017-08-02 08:02 (UTC)

I had to install qt5-webengine from extra to get it working.

Bevan commented on 2017-03-19 16:53 (UTC)

mxr: Yeah, I wasn't too happy about that dependency as well. I looked into all the provided libraries and also links against Removing this though breaks the whole package as it seems to differ from Arch's qt version. Have you run the software now for a while with your modifications and without errors? Then I may just give it a shot and wait if people notice any errors.

mxr commented on 2017-03-04 13:44 (UTC)

This new version of eagle needs libselinux which is quite annoying to compile. I just wanted to note here that is is unnecessary the dependency can be removed by deleting and from the lib/ directory in the package. (Arch Linux' version seems to be alright) Maybe this change can be considered in the PKGBUILD script

R00KIE commented on 2015-10-20 17:11 (UTC)

That patch is already in harfbuzz 1.0.6-1 and eagle still crashes so I suppose it is safe to say that it doesn't fix the problem unfortunately. Hopefully some later release of eagle will not have this problem.

Bevan commented on 2015-10-13 10:13 (UTC)

Hm.. Since it affects at least three people this really seems to be an issue. But I cannot reproduce it. stevenhoneyman posted a patch[1] for harfbuzz on the forums. So maybe that's worth a try. [1]:

R00KIE commented on 2015-10-12 16:49 (UTC)

For me it crashes when I try to maximize the schematic window, the output on dmesg point to somehow being the culprit. I get: eagle[20148]: segfault at 9000000088 ip 00007f35b65e0aa4 sp 00007ffe67f49348 error 4 in[7f35b6565000+19b000] eagle[20161]: segfault at 9000000088 ip 00007f2770aa9aa4 sp 00007fffdac16e58 error 4 in[7f2770a2e000+19b000] traps: eagle[20839] general protection ip:7fba61da3b48 sp:7ffcad551470 error:0 in[7fba61d2c000+19b000]

71GA commented on 2015-10-11 06:59 (UTC)

It keeps crashing whenever I open schematic or layout...

stevenhoneyman commented on 2015-10-05 20:53 (UTC) (edited on 2015-10-05 21:39 (UTC) by stevenhoneyman)

Is anyone having trouble since today with this? It's been fine all weekend, but today if I select a specific part in the library (with the "preview pane"), it crashes. Library works fine on the Windows version, and is my own, not just some random one I found online. freetype2 got an update, but a downgrade back didn't change anything. EDIT: had to downgrade harfbuzz as well. Will ask on the forums

Bevan commented on 2015-08-14 10:04 (UTC)

Thanks for pointing this out. The issue is that the file has dos linebreaks and since AUR is git-based these are transformed into unix linebreaks which of course alters the checksum. I will rework this package soon.

kaysimon commented on 2015-08-14 10:00 (UTC)

Build fails because md5sum of the file eagle.xml isn't correct

Bevan commented on 2015-08-09 07:14 (UTC)

Hmm. If people flag this out-of-date although it is not out-of-date I can't do much but unflag it again…

yuyichao commented on 2015-07-08 12:36 (UTC)

@Bevan Feel free to have it. You can also find the history here[1] but I guess AUR doesn't support history rewrite. [1]

Bevan commented on 2015-07-08 12:21 (UTC)

I just migrated this package to AUR4. If the original maintainer (yuyichao) wants it back I will transfer the ownership back of course. Otherwise I will keep maintaining it.

stevenhoneyman commented on 2015-05-11 19:11 (UTC)

It starts up and announces that this is out of date, 7.3.0 is released.

JetJaguarXP commented on 2015-03-16 00:18 (UTC)

Thank you so much for this package!!

greyltc commented on 2015-02-07 18:47 (UTC)

The below PKGBUILD for 7.2.0 from @ivanovp gives me: ==> ERROR: PKGBUILD contains CRLF characters and cannot be sourced. Otherwise it seems to work fine. I've fixed up the file: @yuyichao please update this package.

ivanovp commented on 2014-12-15 19:49 (UTC)

PKGBUILD for 7.2.0

Harvie commented on 2014-11-05 17:25 (UTC)

@yuyichao: Well 1.) it works under root but not under user, so problem is with package 2.) i've found it works under regular user when executed directly as /opt/eagle/bin/eagle. so problem is probably in /usr/bin/eagle, which is opensource :) 3.) you can still use strace and similar programs to debug closed source binaries if you need...

yuyichao commented on 2014-10-31 13:34 (UTC)

@Harvie Unfortunately this is a closed source software and I have no way to tell why it is behaving like that or how to fix it, especially if it does not produce any useful error messages. If you can somehow use their official install script to produce a workable installation for regular user, I might be able to figure out what's the difference and if there's anything I'm missing for packing. Otherwise, I would suggest asking for help on their forum.

Harvie commented on 2014-10-31 13:27 (UTC)

@yuyichao: no. i've deleted those and they were created again. but it still loops in freeware dialog. even after upgrade from 6.5 to 7.1...

hakunamenta commented on 2014-10-07 19:28 (UTC)

Indeed. The wrapper in question is pacaur, and I noticed that there is a slight difference in the way dependencies are declared between the examples you mentioned and the PKGBUILD here. For nvidia and skype there is a depends line for all $ARCH and a switch further down. for eagle there are no single depends that are for all $CARCH. My guess is, that pacaur only scans for the first occurrence of depends and stops when it fails to resolve that line. In most cases this probably works just fine only in this rare case not. I will send info to pacaur maintainer. Thanks for this fine PKGBUILD

yuyichao commented on 2014-10-07 18:56 (UTC)

`$CARCH` is a standard variable. I'm not sure where it is documented but it is used in some official packages[1][2]. I've tested it on my machine locally and it works. You should also try to build it after downloading with makepkg, and all of the dependencies should be in the official repo. If your AUR helper fetch the dependencies only from the AUR interface rather than from the PKGBUILD itself. It's a bug of the AUR helper. The dependency list on the AUR is generated from .AURINFO, which is in turn generated on a machine with certain architecture. For cases like this that the dependencies are different for different architectures, there's not way (not in the current setup) to make it accurate for both architectures. [1] [2]

hakunamenta commented on 2014-10-07 18:02 (UTC)

current dependencies can not be installed on i686 because (excerpt from aur wrapper follows): :: no results found for lib32-fontconfig :: no results found for lib32-freetype2 :: no results found for lib32-gcc-libs :: […] this is probably because the PKGBUILD uses the var $CARCH which is not defined

yuyichao commented on 2014-04-03 04:24 (UTC)

@Harvie Cannot reproduce. Is there any error messages? Do you already have ~/.eagle/ and ~/.eaglerc? If you do, what's their owner and permission?

Harvie commented on 2014-04-03 04:06 (UTC)

I've got minor problem with this package... /usr/bin/eagle works only when run under root (loops in license dialog under regular user) When i use /opt/eagle/bin/eagle it works as expected...

yuyichao commented on 2014-01-24 12:47 (UTC)

P.S. I didn't bump the pkgrel since there is no need for anyone with the package installed to update.

yuyichao commented on 2014-01-24 12:46 (UTC)

Updated with the additional make dependency. @trgtylcnky: A general rule for AUR is you need to install the base-devel group, which include patch. However, I do agree that these dependencies should be explicitly specified (maybe except glibc and gcc) (although it's easy to miss them...). Also, it is only a make dependency rather than a dependency.

trgtylcnky commented on 2014-01-24 12:39 (UTC)

I think patch should be added to dependencies.

yuyichao commented on 2013-09-06 01:25 (UTC)

@jass0 I did several checks and cannot see where the dependency comes from. Here are what I did. I checked the output of `objdump -p` on `/opt/eagle/bin/eagle` (and that is how I come up with the dependency list) and icu is not there. It's not even pulled in by other libraries since it does not show up in the output of `ldd` either. It is true that Qt4 is dlopen'ing icu using its soname if compiled with icu enabled and eagle seems to be statically linking qt4. However after doing a text search in the elf file, I cannot find anything similar either. The last thing I did was running eagle with icu (in my case lib32-icu) installed and check `/proc/<pid>/maps` and `lsof /usr/lib{,32}/libicu*`. Neither of them shows icu is loaded by eagle. Where did you find that dependency? Is there anything I am missing or misunderstand here?

commented on 2013-09-05 20:17 (UTC)

icu dependency..?

yuyichao commented on 2013-09-01 21:40 (UTC)

Posted on their forum here[1], no idea if it can be merged.... = = .... [1]

yuyichao commented on 2013-09-01 21:26 (UTC)

I have just uploaded a new version of PKGBUILD. It fixed some stupid bugs in the Chinese translation. The problem doesn't exist in other languages so if you are not using Chinese, feel free to igore it (that's why I didn't bump the $pkgrel). P.S. anyone know where to report this bug upstream? It's close sourced and I didn't find anywhere obvious on there website to report bugs....

yuyichao commented on 2013-08-07 13:52 (UTC)

Updated to 6.5.0. libpng14 and libjpeg-turbo are both removed from optdepends. I did a simple search in the elf file and it seems that eagle is statically compiled with libpng 1.5 and I suppose it is similar for libjpeg since I cannot find the string "libjpeg" anywhere. eagle keeps adding random permissions to files/directories (this time setuid). I have removed them in the package. Please tell me if there is any permission related problems that I didn't notice.

commented on 2013-08-07 13:09 (UTC)

Hey, flagged out of date, because version 6.5.0 is out: 721407ee4011d629c843c4c90d2a5082

yuyichao commented on 2013-03-23 22:50 (UTC)

@BotoX: Reason for flag out-of-date? I haven't found a new version on the official website. Or is there a dependency problem or sth like this? Unflag right now, feel free to mark again with a comment for the reason if you think sth is indeed wrong with the package.

yuyichao commented on 2013-02-24 22:06 (UTC)

@ra_fi Good point. Updated (along with some other fixes). THX.

commented on 2013-02-24 21:19 (UTC)

To get a higher resolution program icon (e.g. for gnome3), I would change the Icon line in eagle.desktop to: "Icon=/opt/eagle/bin/eagleicon50.png"

saabzero commented on 2013-01-09 18:51 (UTC)

Thx for the tips @headcra6 and yuyichao! Unfortunately the disabling of desktop effects does not solve this problem. Hopefully this will get fixed with a driver update. I'll try some vsync options, if it does not work i'll be using my laptop as a workaround til then!

headcra6 commented on 2013-01-08 20:49 (UTC)

> The well known fact is that both open-source and proprietary drivers sucks... They just suck in different ways.... True that. Fortunately, it finally dawned on me that I've never used anything that utilizes 3D graphics on my machine, so open source driver is the most suitable choice.

yuyichao commented on 2013-01-08 20:38 (UTC)

@headcra6 Well the unfortunate fact is that even if it is a bug in the eagle program, there is nothing I can help with packaging... (The packaging is really simple, extract an archive and it is done......) Luckily, the problem doesn't seem to be there... There might be some driver options u may want to play with if u still want to use proprietary drivers (vsync and other things that doesn't make sense for me .....). (At least one of my friends had solved a similar problem (with video player) after switching on/off vsync...) The well known fact is that both open-source and proprietary drivers sucks... They just suck in different ways....

headcra6 commented on 2013-01-08 20:24 (UTC)

Whew, problem solved. After enduring it for so long, I've decided to change catalyst driver for xf86-video-ati. @saabzero As you can see, that's how I managed to get rid of those artifacts. But that's kinda radical solution, so maybe try switching off composite first? @yuyichao Thanks, it's just as you suggested. Damn proprietary drivers. Well, it's nice to know that the problem isn't the eagle package.

yuyichao commented on 2013-01-08 19:32 (UTC)

@headcra6 @saabzero The problem looks like a typical fail-to-synchronize/flush, which may caused by either the graphic card driver and/or the compositor (I haven't experienced such a problem before so not really sure about what exactly it is). You may want to try if the problem remain without composite manager (C-S-F12 to turn off composite in kde), it may be a bug in the program itself if the problem disappear without composite. Maybe u r interested to report it upstream.... And anyway, whether or not this is a bug in the driver or this close source program itself, there really isn't much I can help with...... (sorry T-T )

saabzero commented on 2013-01-08 19:18 (UTC)

Hi there, i am expiriencing the same problem as described by headcra6. Using ati hd 6000 series with catalyst-total blobs from aur on kde. Would appreciate any help on this problem!

yuyichao commented on 2013-01-08 13:59 (UTC)

The package is installed to /opt/eagle instead of /opt/eagle-$pkgver now. For dependencies, `libjpeg-turbo` and `libpng14` (or the corresponding lib32 package on x86_64) were listed as dependencies but I cannot find them either in the required `.so` files of the executable nor in the files the program uses at runtime. I removed libpng14 and the program runs with no problem (cannot test libjpeg-turbo since it is required by other packages) so I suppose they are not hard dependencies. Since they might be required by some function I didn't notice, I decide to move them to optdeps. Plz let me know if they are not required by anything at all or where they are required. thx. Just upload two versions within minutes... sorry if that have caused anyone to upgrade twice....

yuyichao commented on 2013-01-08 13:10 (UTC)

@pernix THX, packaging and checking dependencies

pernix commented on 2013-01-08 13:03 (UTC)

eagle 6.4.0 is out md5sum is 5e0b4f2864bdbc1677f2897c69ad20a0

headcra6 commented on 2012-11-05 21:33 (UTC)

I've been experiencing some graphical artifacts since the last update.It appears after clicking on main canvas (either in "Board" or "Schematic" window). Basically, it looks like this Picture becomes normal after zooming in or out. Does anyone have the same problem? Any ideas how to fix it?

R00KIE commented on 2012-10-18 13:48 (UTC)

Forgot to say that you don't need to use ln -sf, just ln -s, the target directories should be empty therefore no need to force the creation of the link, does no harm either.

R00KIE commented on 2012-10-18 12:15 (UTC)

I did test my changes before posting the patch and rsync seemed to be working fine, but your use of cp does without that extra dependency so it's better. Here is a new patch [1] with some small modifications. - Keep your usage of cp, however -r is not needed since it is implied by using -a. - Use versioned symlink instead of directory, I suppose the directory should not be versioned, no other package I know of has a directory with version (maybe except python but that is a special case). The symlink could go away with the next version since an update would break any links anyway, after the transition links should not break anymore (if anyone needs it). - Make link for icon in /usr/share/pixmaps and adjust desktop file for that, if you don't want this then you don't need to create the pixmaps directory. - I suppose you don't really need the TryExec line in the desktop file, if the binary is not there, there is some problem with the user's system or the package. - I suppose you don't need the exec inside, it works without it, I don't know how other packages that need scrips do it. - Please consider keeping the line PKGEXT='.pkg.tar', it saves a lot of time when creating the package, if you don't intend to send the package over the internet there is no need to compress it. [1]

yuyichao commented on 2012-10-17 21:52 (UTC)

@ROOKIE Yes, I also find having to use ~/eagle annoy. some changes on your patch 1, I use cp instead of rsync, I think it is enough without any additional dependency. 2, I just keep the old versioned directory in /opt and use a symlink for /opt/eagle, just in case someone is expecting the old install path (at least for this version)... (maybe not...) 3, ur use of rsync seems broken(afaik), it will create a subdirectory under .eagle if it exists. plz test, thx for suggestions.

R00KIE commented on 2012-10-17 20:55 (UTC)

Here's a patch that will make eagle behave a bit more like as expected [1], however I don't know how much you will like it. Changes: - No personal lib dir is created, the user can change that later. - Now the bundled libraries show up when the program starts. - No more rm -rf, it just seems to be a bad idea to have rm -rf on a script. - New dependency of rsync, the upside is that it should be faster to start when the version changes and it should leave user added files in place.

yuyichao commented on 2012-10-17 16:49 (UTC)

@ROOKIE Well neither the install script nor the startup script creates symlinks in ur home dir afaik... so you shouldn't have the problem with this package... Copying everything every time doesn't sound like a good idea for me either, but since eagle is really doing sth weird (looking for sth systemwide in user directory..... as well as write to this dir) it is a little tricky to do symlinks.... (not hard but basically I cannot simply symlink the directory as a whole) need to find time to do that. And AFAIK it is eagle's install script that installs the package with the version suffix... so now I will just symlink /opt/eagle to /opt/eagle-$pkgver, hopefully that can help you if u r doing ur own trick. suggestions/patches welcome.

R00KIE commented on 2012-10-17 14:26 (UTC)

Could you install into /opt/eagle/ instead of /opt/eagle-$pkgver? Since by default eagle looks for libraries in ~/eagle/lbr, symlinking the libraries in /opt/eagle-$pkgver/lbr into ~/eagle/lbr will break with every update. Changing the configuration to look for libraries in /opt/eagle-$pkgver/lbr will prevent the user from using personal libraries and copying the libraries in /opt/eagle-$pkgver/lbr into ~/eagle/lbr is also not a good idea because the user would not notice if any library gets updated in the package.

yuyichao commented on 2012-10-10 16:36 (UTC)

@swiftgeek well it actually does depend on gcc-libs (you can see this by ldd) although the correct dependency for x86_64 is lib32-gcc-libs (binary for x86) rather than gcc-libs-multilibs (binary for x86_64). Not really sure if it is a direct dependency or pulled in by one of other dependencies (too lazy to check), but since it was here before I will just change the package name rather than remove it. will soon correct it.

swiftgeek commented on 2012-10-10 16:21 (UTC)

@nboichat: Nothing is building here -.-

swiftgeek commented on 2012-10-10 16:21 (UTC)

gcc-libs-multilib is NOT needed. Having it installed triggers bugs in eagle!

pernix commented on 2012-10-10 11:03 (UTC)

md5sum for eagle 6.3.0 x86_64: 661defb4ae9531e829a96c9aaaa16b0e

Tectu commented on 2012-09-17 09:08 (UTC)

Is this package still broken like a year or two ago when I wanted to try it? I couldn't use it back then because it f*cked up my entire build chain. Can I use it without pain?

nboichat commented on 2012-08-19 14:53 (UTC)

Works perfectly on x86_64 architecture if you first run: # pacman -S gcc-multilib As indicated there:

rpodgorny commented on 2012-08-09 17:05 (UTC)

please, be sure to clean up the gcc-libs/multilib mess. shouldn't it be a makedepend instead? is it needed at all? what about lib32-gcc-libs? anyway, i'm running eagle WITHOUT gcc-libs-multilib installed.

commented on 2012-08-02 18:53 (UTC)

Oh thanks, that's easy. I trust it won't interfere with the installed libpng15 in any bad way?

yuyichao commented on 2012-08-02 16:28 (UTC)

libpng14 is another aur package. U can use a aur tool like yaourt to download that automatically or u can install it manually if u r using makepkg.

commented on 2012-08-02 16:23 (UTC)

Well the package doesn't work (libpng14 not found), but I didn't understand how to fix this, in case it was supposed to be hidden in the other comments here >_> Any help appreciated.

rpodgorny commented on 2012-07-25 00:52 (UTC)

ha! stupid me! ...anyway, it almost looks like we have the same problem as other distros: (why on earth don't they at least bundle the libs if they don't want to link statically?)

rpodgorny commented on 2012-07-25 00:38 (UTC)

replaced "gcc-libs-multilib" with "gcc-libs" and "lib32-libpng14" with "lib32-libpng" and it builds. still, i get: ./eagle: error while loading shared libraries: cannot open shared object file: No such file or directory

swiftgeek commented on 2012-07-07 21:05 (UTC)

Works great with gcc-libs (doesn't need gcc-libs-multilib)

mandos commented on 2012-06-22 12:13 (UTC)

After installing eagle I get the following error: ./eagle: error while loading shared libraries: cannot open shared object file: No such file or directory However I believe that libpng14 is now libpng15 (right?).

z0id commented on 2012-03-29 18:19 (UTC)

lipng dependency should be changed to libpng14. The libpng version in repos is 1.5 now.

commented on 2012-03-14 22:54 (UTC)

@shrimants You need to have the multilib repo enabled gcc-multilib allows you to build 32 bit stuff on 64 bit.

commented on 2012-03-14 22:20 (UTC)

I'm getting an error: Dependency `gcc-libs-multilib' of `eagle' does not exist. Do I need to have the 32 bit repos enabled to use this?

bbandi commented on 2012-02-14 08:38 (UTC)

I agree with amstan. Also, lib32-libpng14 should be in the depends array.

amstan commented on 2012-02-13 14:23 (UTC)

Could you please change the so it accepts arguments? Otherwise this happens: alex@alex-laptop:~% eagle /tmp/ep.brd install: cannot create directory `/tmp/ep.brd': File exists And then it puts /tmp/ep.brd in the lib directories setting for some reason.

Kompilator commented on 2012-02-06 08:33 (UTC)

For x86_64 please replace lib32-png with lib32-libpng14.

commented on 2011-12-20 17:52 (UTC)

For x86_64 please remove for the depends: - lib32-libpng12 - lib32-openssl-compat - lib32-libjpeg6 and add: - lib32-libjpeg-turbo - lib32-openssl - lib32-png

commented on 2011-12-19 14:26 (UTC)

v6.0.0 seems to be working fine on x86_64.. I had to delete both ~/.eaglerc and ~/.eagle/ otherwise it would give errors at program startup. Thanks for maintaining the package!

mortzu commented on 2011-12-13 14:46 (UTC)

updated. hope it works

pernix commented on 2011-12-13 12:23 (UTC)

Version 6.0.0 is out. md5sum for x86_64 is a3265d222a68c5d7251384063e63e5fc

commented on 2011-09-21 21:02 (UTC)

Alas. The error I mention occurs only when on an NFSv4 mount. I still can't explain why it works "by hand". A similar discussion about postgres is here:

commented on 2011-09-21 20:48 (UTC)

This package fails to build for me. In particular, I receive the following: ... /bin/tar: eagle-5.11.0/doc/README_en: Cannot change ownership to uid 507, gid 200: Invalid argument /bin/tar: eagle-5.11.0/doc: Cannot change ownership to uid 507, gid 100: Invalid argument /bin/tar: eagle-5.11.0: Cannot change ownership to uid 507, gid 100: Invalid argument /bin/tar: Exiting with failure status due to previous errors Error while extracting data from '' ==> ERROR: A failure occurred in build(). Aborting... Thanks. Jacob

bongo commented on 2011-09-20 19:34 (UTC)

@edenyard yes the current cfg collides with gcc & the various libs but it doesn't hurt to install the multilib versions since that just means additional support for x86. I think it just enables --enable-multilib so your building env works as before. It builds fine after the replacements.

commented on 2011-09-14 18:47 (UTC)

This no longer builds with an up-to-date Arch 64-bit system. It requires gcc-libs-multlib which conflicts with the existing gcc-libs. Without gcc-multilib, it seems that the other dependencies (lib32-libjpeg6, lib32-libpng12 and lib-ssl-compatibility) cannot be built either. Is there any way around this, please?

commented on 2010-11-11 21:52 (UTC)

please add lib32-openssl-compatibility and lib32-libpng12 to depends array for x86_64 Thanks

mortzu commented on 2010-11-01 10:49 (UTC)

install it from AUR

commented on 2010-11-01 10:39 (UTC)

Does fail to create a working package… [nils@Eagle eagle]$ makepkg ==> Erstelle Paket: eagle 5.10.0-3 (Mo 1. Nov 11:31:21 CET 2010) ==> Prüfe Laufzeit-Abhängigkeiten... ==> Fehlende Abhängigkeiten: -> libjpeg6 -> libpng12 -> openssl-compatibility ==> Prüfe Buildtime-Abhängigkeiten... ==> FEHLER: Konnte nicht alle Abhängigkeiten auflösen. Using '-s' to install dependencys doesn't fix that, because the eagle requires older versions of libpng, libjpeg etc. What to do?

mortzu commented on 2010-06-18 11:01 (UTC)


commented on 2010-06-18 10:44 (UTC)

Something is wrong with the download path in PKGBUILD: I get this: The following sources will be downloaded:${pkgver%.*}/ Then download fails. If I substitute ${pkgver%.*} with 5.10 it works.

jcci commented on 2010-06-08 03:47 (UTC)

eagle 5.10.0-1 Incompatible with (lib32-)openssl 1.0.0.a-2. Install (lib32-)openssl-compatibility 0.9.8-1 from AUR, or better add to dependencies. Wow, now with Chinese version. Some guys in my company will be pretty happy. Thanks for maintaining!

commented on 2010-04-27 17:13 (UTC)

6,7c6,7 < pkgver=5.9.0 < pkgrel=1 --- > pkgver=5.7.0 > pkgrel=4 20c20 < md5sums=('dc8311b043469a567b40fb87815ab0ef' --- > md5sums=('0f707d872b67b0a900c7810baebaedb9'

commented on 2010-04-13 11:03 (UTC)

6,7c6,7 < pkgver=5.8.0 < pkgrel=1 --- > pkgver=5.7.0 > pkgrel=4 20c20 < md5sums=('39e948ade07fa6e914820c68b9286c35' --- > md5sums=('0f707d872b67b0a900c7810baebaedb9'