Why is pip always outputting warnings? - terminal

Why is pip always outputting warnings when installing packages? For instance, I just installed nodeenv and got a bunch of these:
warning: no previously-included files found matching '*.pyc'
warning: no previously-included files found matching '*.swp'
This is not a problem, the packages I install works fine. I'm just curious to why these warnings occur, what they mean and if they somehow can be hidden without suffocating important errors.

It doesnt do that for me... and looking at the source I don't think it will for anyone in the future.
As you can see here, these warnings were removed in Dec 2014. It would appear that they would have been triggered for cases where a manifest directive was overly cautious and excluded files that had not actually been included.

Related

gcc 10.3.1.1.fc32 build failing with "gcc: fatal error: ‘-fuse-linker-plugin’, but liblto_plugin.so not found"

I have some older utilities that are only sometimes needed and it came time to use a particular one and I found it didn't work. I know that some of the other utilities in the same package were working, but rather than worry about why this one was unique, I figured it just needed a recompile on the most recent Fedora and so I ran make.
I then learned that it couldn't find cc1. So the first thing I did was: dnf update gcc
This upgraded some 11 packages but didn't cure the cc1 problem, so I did which gcc to find where that is, then made a soft link to the cc1 program in the same directory. The compile then proceeded until a / the final linking, which should be:
gcc -o run${BINTYPE} run.o hashc.o
'run' here is the utility name. But the compile returns:
gcc: fatal error: ‘-fuse-linker-plugin’, but liblto_plugin.so not found
compilation terminated.
I then did a web search and found a few stack-overflow entries, such as this one, (and a handful of non-stack-overflow pages, too) but none matched or provided a working solution.
I then found where liblto_plugin.so actually is:
/usr/lib64/bfd-plugins/liblto_plugin.so
...and checked LD_LIBRARY_PATH - the location wasn't in there, so I added it as the first entry (/usr/lib64/bfd-plugins/). That didn't work - same error.
And, I also tried going to where this distribution of Fedora seems to want to find it - which is /usr/libexec/gcc/x86_64-redhat-linux/ - and then making a soft link there, too, but that didn't work either.
OK, this should be simple, but I'm stumped!
It might be worth noting that from what I understand, this plugin is about optimizing dynamic linking at runtime, and that's simply not involved for this utility. All this program does is validate an environment before running to ensure it doesn't even try to launch unless certain conditions are met, so static linking should work fine. So maybe a workaround is to simply provide a flag that says skip the plug-ins? I'd rather "fix it correctly," but I'll settle for it doing what I need to do right now.
UPDATE
As suggested by Knud Larsen in comments, I did a re-installation of gcc and nothing changed. And, it appears the ‘-fuse-linker-plugin’ isn't even rquired these days, Great! But, there's no flag calling for its use, so it seems to be automatic; how do I turn this thing off?!
I also meet this question when install something with cargo.
note: cc: fatal error: '-fuse-linker-plugin', but liblto_plugin.so not found
compilation terminated.
Finally, I found the reason. I created the hard link cc of gcc by mistake. It should have been a soft link. It will be fine after changing it.

Are there obvious sources for the Brew Doctor warnings I'm seeing?

I have recently installed Hombrew on Yosemite with Xcode installed and would like to better understand what brew doctor is warning me about. I understand that these warnings are nothing to worry about (until they are) and am not asking how or whether to respond to them; but I would like to do the best I can to understand the likely causes so that I can be prepared when issues come up (and also to head off issues that others in my office may encounter on similar systems).
Are any of the items below from obvious sources on a 10.10 machine with Xcode and non-brew Fortran installed? Do any of these items ring a bell?
Warning: Some directories in /usr/local/share/man aren't writable.
This can happen if you "sudo make install" software that isn't managed
by Homebrew. If a brew tries to add locale information to one of these
directories, then the install will fail during the link step.
You should probably `chown` them:
/usr/local/share/man/de
/usr/local/share/man/de/man1
/usr/local/share/man/mann
Warning: Broken symlinks were found. Remove them with `brew prune`:
/usr/local/lib/libasan.dylib
/usr/local/lib/libatomic.dylib
/usr/local/lib/libcilkrts.dylib
/usr/local/lib/libgcc_s_ppc64.1.dylib
/usr/local/lib/libgcc_s_x86_64.1.dylib
/usr/local/lib/libgfortran.dylib
/usr/local/lib/libgmp.dylib
/usr/local/lib/libgmpxx.dylib
/usr/local/lib/libgomp.dylib
/usr/local/lib/libitm.dylib
/usr/local/lib/libmpc.dylib
/usr/local/lib/libmpfr.dylib
/usr/local/lib/libquadmath.dylib
/usr/local/lib/libssp.dylib
/usr/local/lib/libstdc++.dylib
/usr/local/lib/libubsan.dylib
/usr/local/lib/ppc64/libgfortran.2.0.0.dylib
/usr/local/lib/ppc64/libgfortran.2.dylib
/usr/local/lib/ppc64/libgfortran.dylib
/usr/local/lib/x86_64/libgfortran.2.0.0.dylib
/usr/local/lib/x86_64/libgfortran.2.dylib
/usr/local/lib/x86_64/libgfortran.dylib
Warning: "config" scripts exist outside your system or Homebrew directories.
`./configure` scripts often look for *-config scripts to determine if
software packages are installed, and what additional flags to use when
compiling and linking.
Having additional scripts in your path can confuse software installed via
Homebrew if the config script overrides a system or Homebrew provided
script of the same name. We found the following "config" scripts:
/opt/ImageMagick/bin/Magick++-config
/opt/ImageMagick/bin/Magick-config
/opt/ImageMagick/bin/MagickCore-config
/opt/ImageMagick/bin/MagickWand-config
/opt/ImageMagick/bin/Wand-config
Warning: Unbrewed header files were found in /usr/local/include.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected header files:
/usr/local/include/fakemysql.h
/usr/local/include/fakepq.h
/usr/local/include/fakesql.h
/usr/local/include/gmp.h
/usr/local/include/gmpxx.h
/usr/local/include/graphviz/arith.h
/usr/local/include/graphviz/cdt.h
/usr/local/include/graphviz/cgraph.h
/usr/local/include/graphviz/color.h
/usr/local/include/graphviz/geom.h
/usr/local/include/graphviz/graphviz_version.h
/usr/local/include/graphviz/gvc.h
/usr/local/include/graphviz/gvcext.h
/usr/local/include/graphviz/gvcjob.h
/usr/local/include/graphviz/gvcommon.h
/usr/local/include/graphviz/gvconfig.h
/usr/local/include/graphviz/gvplugin.h
/usr/local/include/graphviz/gvplugin_device.h
/usr/local/include/graphviz/gvplugin_layout.h
/usr/local/include/graphviz/gvplugin_loadimage.h
/usr/local/include/graphviz/gvplugin_render.h
/usr/local/include/graphviz/gvplugin_textlayout.h
/usr/local/include/graphviz/gvpr.h
/usr/local/include/graphviz/pack.h
/usr/local/include/graphviz/pathgeom.h
/usr/local/include/graphviz/pathplan.h
/usr/local/include/graphviz/textspan.h
/usr/local/include/graphviz/types.h
/usr/local/include/graphviz/usershape.h
/usr/local/include/graphviz/xdot.h
/usr/local/include/itcl.h
/usr/local/include/itcl2TclOO.h
/usr/local/include/itclDecls.h
/usr/local/include/itclInt.h
/usr/local/include/itclIntDecls.h
/usr/local/include/itclMigrate2TclCore.h
/usr/local/include/itclTclIntStubsFcn.h
/usr/local/include/mpc.h
/usr/local/include/mpf2mpfr.h
/usr/local/include/mpfr.h
/usr/local/include/mysqlStubs.h
/usr/local/include/odbcStubs.h
/usr/local/include/pqStubs.h
/usr/local/include/tcl.h
/usr/local/include/tclDecls.h
/usr/local/include/tclOO.h
/usr/local/include/tclOODecls.h
/usr/local/include/tclPlatDecls.h
/usr/local/include/tclThread.h
/usr/local/include/tclTomMath.h
/usr/local/include/tclTomMathDecls.h
/usr/local/include/tdbc.h
/usr/local/include/tdbcDecls.h
/usr/local/include/tdbcInt.h
/usr/local/include/tk.h
/usr/local/include/tkDecls.h
/usr/local/include/tkPlatDecls.h
Warning: Unbrewed .la files were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected .la files:
/usr/local/lib/libasan.la
/usr/local/lib/libatomic.la
/usr/local/lib/libcilkrts.la
/usr/local/lib/libgfortran.la
/usr/local/lib/libgmp.la
/usr/local/lib/libgmpxx.la
/usr/local/lib/libgomp.la
/usr/local/lib/libitm.la
/usr/local/lib/libmpc.la
/usr/local/lib/libmpfr.la
/usr/local/lib/libquadmath.la
/usr/local/lib/libssp.la
/usr/local/lib/libssp_nonshared.la
/usr/local/lib/libstdc++.la
/usr/local/lib/libsupc++.la
/usr/local/lib/libubsan.la
Warning: Unbrewed .pc files were found in /usr/local/lib/pkgconfig.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected .pc files:
/usr/local/lib/pkgconfig/libcdt.pc
/usr/local/lib/pkgconfig/libcgraph.pc
/usr/local/lib/pkgconfig/libgvc.pc
/usr/local/lib/pkgconfig/libgvpr.pc
/usr/local/lib/pkgconfig/libpathplan.pc
/usr/local/lib/pkgconfig/libxdot.pc
/usr/local/lib/pkgconfig/tcl.pc
/usr/local/lib/pkgconfig/tk.pc
Warning: Unbrewed static libraries were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected static libraries:
/usr/local/lib/libatomic.a
/usr/local/lib/libcilkrts.a
/usr/local/lib/libgfortran.a
/usr/local/lib/libgmp.a
/usr/local/lib/libgmpxx.a
/usr/local/lib/libgomp.a
/usr/local/lib/libitm.a
/usr/local/lib/libmpc.a
/usr/local/lib/libmpfr.a
/usr/local/lib/libquadmath.a
/usr/local/lib/libssp.a
/usr/local/lib/libssp_nonshared.a
/usr/local/lib/libstdc++.a
/usr/local/lib/libsupc++.a
/usr/local/lib/libtclstub8.6.a
/usr/local/lib/libtkstub8.6.a
There is a variety of warnings here, probably all with a very similar cause: having installed software from source (by compiling with configure; make; make install, or sometimes unpacking a very specific (e.g. scientific) package, such as fortran). That would be mostly software with a unix background, and the software decided to install itself in /usr/local.
I don't know your background, so I'm going to expand somewhat (I'll probably miss a few things or may have a few things (somewhat) incorrect):
In unix & linux, a piece of software is often distributed across various subdirectories, and not inside a single package (which is more Mac style). It can consist of binary that goes into /usr/local/bin/, a library with routines used by the binary that is put in /usr/local/lib/, some header file for function declarations that lives in /usr/local/include/, a manual page that is put in /usr/local/man/ or additional (e.g. configuration) data that could go into /usr/local/share/. Practically any combination can exist.
That looks a bit scattered, but it works. It does mean that pieces of different software live in the same subdirectory, as you can see form the various lists of filenames.
Note that /usr/local/ is in so far unique, that it tends to be a preferred directory to install extra software: software that the system (OS) can do without. This is also why Homebrew likes to install software there. Other software managers avoid the unix default of /usr/local/ and install in /opt/local/ (Macports) or /sw/ (Fink). But the fact that Homebrew picks the default "extra" software installation part can mean it clashes with other installed software.
Your system software lives in plain /usr/, or /System/ and /Library/, and stays out of /usr/local/; if you remove /usr/local/ completely, your system will still work.
So, with that in mind, the warnings:
Warning: Some directories in /usr/local/share/man aren't writable.
This can happen if you "sudo make install" software that isn't managed
by Homebrew. If a brew tries to add locale information to one of these
directories, then the install will fail during the link step. You
should probably chown them:
/usr/local/share/man/de
/usr/local/share/man/de/man1
/usr/local/share/man/mann
Other software installed its manual pages here, likely with the sudo command (you may simply have had a dialog asking for your password; sudo then happened under the hood). In that case, those specific directories are "owned" by "root", and not by the usual Homebrew user (your login). That would mean Homebrew can't, in a future event, not write in those directories, if it ever comes across software that likes its manual pages there, since it's not owned by the Homebrew user.
You can alleviate this by changing the permissions to yourself:
$ sudo chown -R <user>:<group> /usr/local/share/man/de
$ sudo chown -R <user>:<group> /usr/local/share/man/mann
(do an $ ls -l $HOME to find your <user> and <group> to fill in: it's the hopefully obvious columns.)
Warning: Broken symlinks were found. Remove them with `brew prune`:
A sym(bolic )link is just a pointer to a file that exist somewhere else. If it's broken, the original file doesn't exist anymore, or the symlink is pointing to the wrong place. You can see what it is pointing at by doing for example:
ls -l /usr/local/lib/libasan.dylib
The .dylib files are all dynamic libraries: library files that contain functions, and are meant to be used by other programs (but, specifically, not fully included inside that program; see later on static libraries). A broken library file is a potentially bad thing: new software that wants to use those files may think "ah, I can use this library" and then things go bad during compilation, when it turns out the file doesn't exist anymore. So, it may be wise to prune (remove) the symbolic links. (A symbolic link can normally be safely removed, even if it points correctly: it's only a pointer, the original file is left untouched.)
Warning: "config" scripts exist outside your system or Homebrew directories.
`./configure` scripts often look for *-config scripts to determine if
software packages are installed, and what additional flags to use when
compiling and linking.
Having additional scripts in your path can confuse software installed via
Homebrew if the config script overrides a system or Homebrew provided
script of the same name. We found the following "config" scripts:
configure is part of the chain to build software from source on the command line. It looks around on your system for existing libraries, and also ask for the configuration of programs using these -config scripts. Homebrew had a look around, and found such scripts outside the usual directories. Thus, configure could find multiple versions of the same config script, get confused which one to use and use the wrong one.
In this case, it's all ImageMagick stuff. Depending how you use it, you could opt to remove the entire /opt/ImageMagick/ directory (and perhaps you're then left with an empty /opt/ directory, in which case you can also remove /opt/; it's not part of the usual system).
Warning: Unbrewed header files were found in /usr/local/include.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Warning: Unbrewed .la files were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Warning: Unbrewed static libraries were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
These are all related, and related to the dynamic libraries mentioned before. The .a files are static libraries: they (also) contain often-used functions, but those files get included inside the binary when compiling software from source (thus, the binary becomes bigger than with dynamic libraries). The .h files are header files, which tell programs what the library files contain; the .la have some extra information on the .a library files.
The warning tells you that Homebrew may get confused when installing new software: perhaps it will try to use these libraries, but they happen to be the (oh so slightly) wrong version and things don't work. You don't know until you bump into it, unfortunately.
Warning: Unbrewed .pc files were found in /usr/local/lib/pkgconfig.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
pkgconfig files are similar to those config scripts mentioned earlier: they contain configuration information if you need some earlier installed software to build new software. Again, as before: versions may mismatch slightly and then things could not work as intended (it doesn't install, or crashes, or makes your computer pass the Turing test).
As for how you may have gotten all those files in /usr/local.? Probably you installed a package that puts everything in /usr/local/ as well. As mentioned, it is a default place to put things. Since it features libgfortran and libgomp, I'm inclined to think about some scientific package.
All in all, most warnings are about potential incompatibilities: Homebrew, like most package/software managers, tries to hold some grip (not too tight though) on what it installs and what is around, because backwards incompatibilities and such can mean that newly installed software from source ("brewed" software) doesn't properly install or run. As an example, Macports is more strict (at least it was years ago when I used it), and will download matching, known compatible, versions of required extra software (thus, you could end up with four different versions of a C compiler).
Homebrew tries to be lenient with respect to installed libraries and such, but it does warn you that bad things can happen, either during compilation or later on.

Failing to install mingw: mingw-get-gui: *** ERROR *** unexpected end of archive reading header record

I am now trying to install mingw for a couple of hours, however I keep on getting the following error message:
"install: gcc-c++-4.8.1-4-mingw32-bin.tar.lzma
installing gcc-c++-4.8.1-4-mingw32-bin.tar.lzma
mingw-get-gui: * ERROR * unexpected end of archive reading header record"
and cannot find any solution to my problem. I tried to reinstall 7zip, because I thought it may caused from that. I am trying to install gcc on a 32-bit Windows 7. I would be really happy for any suggestions.
Bye!
Even though this is an old question, I will post an answer, in case other users come across this again.
I encountered the same problem:
at first I did not notice that something went wrong with the installation/upgrade itself, because the graphical update manager showed a line like "everything went successful" ...
if I had bothered to look into the log details, I would have seen the error messesage mingw-get-gui: * ERROR * unexpected end of archive reading header record and immediately known, that something went wrong (its really misleading, to show a dialog saying that a task was completed successfully when there were errors!).
But pertaining to your problem (or at least this was, what caused mine):
Cause
most likely something went wrong, when the mentioned archive file was downloaded. Unfortunately, mingw-get seems to ignore download errors and continues as if nothing went wrong... thus the error message archive header record is invalid, because it is not really an archive file, but a text file containing the HTML error message.
To complicate things further, mingw-get caches these files and when you try to re-install the packages it uses these invalid, cached files.
Solution
One way of fixing this, would be to delete the cached files and then re-install the package.
The cached files should be at
<mingw directory>\var\cache\mingw-get\packages
e.g.
C:\MinGW\var\cache\mingw-get\packages
Side Note: if you "lost" the error message like me, and don't know, for which packages there was an error, you can search the cache directory for files which contain the HTML error message, e.g. a search term like <html> should work; also these files are quite small, but there may also be other valid packages with small file size to this is no unambiguous criterion
If you continue to get error messages * ERROR * unexpected end of archive reading header record with the mingw-get tool you could also try to download the file manually and place it in the folder for the cached packages.
For re-installing the packages you could use the graphical interface of mingw-get (e.g. remove and then install the package) or, for example the command line version
mingw-get --reinstall install <package name>
for mingw packages the <package name> is usually just the prefix of the file name (before the first version number), e.g. for
libiconv-1.14-3-mingw32-dev.tar.lzma
the package name would be libiconv. For msys packages the package name usually has the prefix msys-, e.g. something like msys-libopts
(you should be able to see if it's a mingw or a msys package by looking at the part of the file name that comes after the first version number, e.g. for libiconv-1.14-3-mingw32-dev.tar.lzma: ...3-mingw32-de...)

Brew Doctor Warning

I see the following when I run brew doctor:
Warning: Unbrewed dylibs were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected dylibs:
/usr/local/lib/libMonoPosixHelper.dylib
/usr/local/lib/libSFFileMonitor.32.dylib
/usr/local/lib/libSFIPC.32.dylib
/usr/local/lib/libSFIPC.I.dylib
/usr/local/lib/libSFsqlite3.7.4.dylib
/usr/local/lib/libSFSyncEngine.I.dylib
Does anyone have any suggestions on how to approach this warning and potentially fix the problem?
This particular set of files appears to be from Citrix Receiver; I received the exact same message after installing brew, and a bit of googling turned up http://arstechnica.com/civis/viewtopic.php?f=19&t=1188699
I'd recommend leaving them in place unless you no longer need Citrix.

Unexpected dylib, la, and pc files with fresh mountain lion install

Just reinstalled osx and only installed chrome, sublime, and xcode cli tools so far. I got these warnings from brew doctor:
Warning: Unbrewed dylibs were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected dylibs:
/usr/local/lib/libmacfuse_i32.2.dylib
/usr/local/lib/libmacfuse_i64.2.dylib
/usr/local/lib/libosxfuse_i32.2.dylib
/usr/local/lib/libosxfuse_i64.2.dylib
Warning: Unbrewed .la files were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected .la files:
/usr/local/lib/libosxfuse_i32.la
/usr/local/lib/libosxfuse_i64.la
Warning: Unbrewed .pc files were found in /usr/local/lib/pkgconfig.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected .pc files:
/usr/local/lib/pkgconfig/osxfuse.pc
Is it safe to remove these files or should I just ignore the warnings?
Do you, by any chance, have TrueCrypt or OSXFuse installed? Because your problem looks like this or this. The TrueCrypt problem is fixed by this script, and if you have OSXFuse, you can just remove it and use homebrew's version instead.
There's nothing wrong with the answer #Bogdan gives (I upvoted it) but in case it doesn't work for anyone, this script of mine also provides a one-shot solution--just run it, and you're good.

Resources