I am trying to install pg_partman on my Mac. I have tried both my M1 mac and Intel mac. Both of them return the following error when I run make install: Makefile:27: *** missing separator. Stop.
Line 27 contains:
sql/$(EXTENSION)--$(EXTVERSION).sql: $(sort $(wildcard sql/types/*.sql)) $(sort $(wildcard sql/tables/*.sql)) $(sort $(wildcard sql/functions/*.sql)) $(sort $(wildcard sql/procedures/*.sql))
This error is usually due to spaces instead of tabs. However I get this error when I run make install on any of the released versions of pg_partman. I opened an Issue with the pg_partman team and they have no issues running make install, but I believe they are running it on a Linux machine.
I thought it might be due to my M1 mac but when I run on my Intel mac I get the same error. I'm at a complete loss. Machine details below
MacOS Monterey: 12.3.1
which make: /usr/bin/make
make --version:
GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This
is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
This program built for i386-apple-darwin11.3.0
Using sudo in sudo make install fixed my issue.
Related
I'm having issues getting the ODBC driver for Snowflake to work on an M1 Apple Silicon Mac running Big Sur.
Successfully following the instructions on Snowflake's website gets me to the point where testing the driver from the command line (using iodbctest) using the DSN results in the following error:
1: SQLDriverConnect = [iODBC][Driver Manager]dlopen(/opt/snowflake/snowflakeodbc/lib/universal/libSnowflake.dylib, 6): no suitable image found. Did find:
/opt/snowflake/snowflakeodbc/lib/universal/libSnowflake.dylib: no matching architecture in universal wrapper
/opt/snowfl (0) SQLSTATE=00000
2: SQLDriverConnect = [iODBC][Driver Manager]Specified driver could not be loaded (0) SQLSTATE=IM003
My Snowflake driver is installed to /opt/snowflake/snowflakeodbc, so that is correct -- I'm suspicious that this is specifically an M1 problem. I'm using the 2.24.1 version of the driver available from the download mirror here, and the path to the driver in /etc/odbcinst.ini is /opt/snowflake/snowflakeodbc/lib/universal/libSnowflake.dylib (which exists and seems, from all my research, that it should be right).
When I run a connection via DBI in R, I get a completely different error:
Error: nanodbc/nanodbc.cpp:1021: 00000:
[Snowflake][ODBC] (11560) Unable to locate SQLGetPrivateProfileString function.
In other StackOverflow posts, people have referenced the above error meaning that there is a missing library of some kind (IODBC isn't configured correctly?), but I've tried quite a few things to no avail. Any guidance would be great.
Tinkered with this a bit more and realized it's an artifact of the installation pathways for the .dmgs & the preset paths in simba.snowflake.ini.
You need to point the Snowflake driver towards the iODBC dylib (as per a sideswiping statement in the docs) -- the driver is originally configured to look for the ODBC dylib (not iODBC) in a folder that's on the path.
When you install the iODBC driver, verify that it is installed to /usr/local/iODBC (this was where my Silicon Mac installed it to) -- and that /usr/local/iODBC/lib has libiodbc.dylib in it. If so, navigate to your installed snowflake driver directory (should be /etc/snowflake) and alter the simba.snowflake.ini file (/etc/snowflake/snowflake/snowflakeodbc/universal/simba.snowflake.ini). You want to uncomment & alter the last line to be both uncommented & point with a full path towards the iODBC dylib (instead of the default, which is the ODBC dylib).
# Darwin specific ODBCInstLib
# iODBC
ODBCInstLib=/usr/local/iODBC/lib/libiodbcinst.dylib
Make sure to comment out any other ODBCInstLib line so that only one is configured. That should enable you to get your connection to snowflake up and running on an M1 Mac.
Big Sur is macOS v11.n
Snowflake supports macOS 10.14 and 10.15 Supported OSs
So what you are trying to do is not supported and is unlikely to work
None of the other solutions worked for me but #kiran-kumawat 's answer set me down a path that worked.
It seems like the core of the issue is that the odbc code is looking for arm64 architecture drivers but Snowflake is providing it in x86_64 architecture. By installing an x86_64 versions of odbc we are able to have it successfully talk to the driver.
First I uninstalled R and Rstudio. (it may be possible to sim-link or change things behind the scenes to make this work with existing installs but I am not sure).
Then install rosetta (apples software for translating between architectures) and a version of homebrew built with it. I am leaving my main version of homebrew in place.
softwareupdate --install-rosetta
arch -x86_64 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"
Then use that version of homebrew to install odbc, R, and Rstudio.
arch -x86_64 /usr/local/Homebrew/bin/brew install unixodbc
arch -x86_64 /usr/local/Homebrew/bin/brew install --cask rstudio
arch -x86_64 /usr/local/Homebrew/bin/brew install --cask r
We then need to install the snowflake driver: https://sfc-repo.snowflakecomputing.com/odbc/mac64/latest/index.html
Click through all the install prompts.
Modify your files
/usr/local/etc/odbcinst.ini:
[Snowflake Driver]
Driver = /opt/snowflake/snowflakeodbc/lib/universal/libSnowflake.dylib
/usr/local/etc/odbc.ini
[Snowflake]
Driver = Snowflake Driver
uid = <uid>
server = <server>
role = <role>
warehouse = <warehouse>
authenticator = externalbrowser
We also need to modify the simba.snowflake.ini file.
It is somewhat locked down so run:
sudo chmod 646 /opt/snowflake/snowflakeodbc/lib/universal/simba.snowflake.ini
Then
vim /opt/snowflake/snowflakeodbc/lib/universal/simba.snowflake.ini
And find the ODBCInstLib line that is uncommented and change it to:
ODBCInstLib=/usr/local/Cellar/unixodbc/2.3.9_1/lib/libodbcinst.dylib
After setting this up I was able to use this connection successfully:
install.packages("DBI")
install.packages("odbc")
con <- DBI::dbConnect(odbc::odbc(), "Snowflake")
one of our team member suggested below steps and it worked for us for Apple M1 series
Install the latest snowflake driver
Uninstall m1 based homebrew using cmd
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/uninstall.sh)"
Install intel based homebrew - restart terminal when done
arch -x86_64 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"
Re-install unixodbc
arch -x86_64 brew install unixodbc
Test
isql -v Pattern
in your database.yml file for connection to snowflake make following change-
replace "dsn: <DSN_NAME>" with following
conn_str: "Driver={PATH};Locale=en-US;uid={USER_NAME};pwd= {PASSWORD};server=<yours>.snowflakecomputing.com;role=<ROLE>;charset=UTF-8;warehouse=<WAREHOUSE>;database=<DATABASE>;schema=<SCHEMA>;"
Has anyone gotten this to work? I use excel w odbc to refresh snowflake files and have tried multiple ways to move the drivers etc and followed snowflake instructions but never works. I did get parallels to work running windows arm but would prefer to just do this in Mac OS
I also have a M1 (version Monterey 12.0) and I ran into similar issues when I tested the driver. Nevertheless, when I tried the "real connection" it worked like a charm. So, maybe it would be good for you to go and test the "real connection" to avoid a wasting of time using such testing. Hope you find this useful.
I am on a VM spun up by Google Compute Engine, running Debian 9.13. I am having problems installing R packages to both R 3.3.3 and R 4.0.1, with non-zero exit status preventing successful install. One of the remedies from other answers here and in RStudio Community is to make sure gcc is updated. So I follow the instructions for Debian 9.13 and do:
sudo apt install build-essential
... which tells me that build-essential is already the newest version (12.3). But when I check the gcc version it shows me a very old version:
User#myvm-1:/usr/local/ $ gcc --version
gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Because this is on a GCE VM, I am wondering if there is a simpler way to update the compiler -- or if there is a completely different way to help get my R packages to install without the non-zero exit status error. Any insights would be appreciated.
Let's back off a little here. You choose Debian 9.13, or the 13th and final version of "oldstable" (see https://www.debian.org/News/2020/20200718).
If you want newer tools, maybe you should start with Debian 10 aka "stable"? (I happen to be a strong believer in using Debian "testing" which I use for example as the basis of the official "r-base" Rocker container for R, but that is a different story. You could also use Ubuntu LTS which tends to be newer than Debian stable which is very conservative). Now, even if you stay with Debian stable I think you will get gcc-7 or gcc-8.
Next, we need to see the actual compilation errors to help you.
Lastly, know that Debian has a) a fair number of binary packages for R and b) very good "backported" packages of R itself at CRAN in the directory http://cloud.r-project.org/bin/linux/debian/
I'm in a team that is running multiple cronjobs that call R scripts from a remote machine (macos). My colleague needs to run 3.6 for a new script, while a package that is essential to mine has not been updated for it yet. I'm trying to put multiple installations on the same computer so we just specify which "R" version to call in the cronjob.
I know installing from source isn't recommended on macos, so I've been trying to follow the directions here https://cran.r-project.org/doc/manuals/r-patched/R-admin.html#Multiple-versions and ran the pkgutil --forget commands to prevent the R 3.6 installation from overwriting the R.framework/Versions/3.5 directory.
Here are the pkgutil commands that I ran:
sudo pkgutil --forget org.r-project.x86_64.tcltk.x11
sudo pkgutil --forget org.r-project.R.el-capitan.GUI.pkg
sudo pkgutil --forget org.r-project.R.el-capitan.fw.pkg
sudo pkgutil --forget org.r-project.x86_64.texinfo
Yet after installing 3.6 from CRAN, when I run the following line:
Library/Frameworks/R.framework/Versions/3.5/Resources/bin/R
Instead of the 3.5.3 console running in the terminal, the 3.6 console pops up.
I'm confused with what to do here - I've also used
ls -la 3.5/Resources/bin | grep "/->"
to check and see if a symlink was created during the install that would change the version/location but get no results, and when I run Rscript --version in the same directory as the R path shown above, I get the following output:
R scripting front-end version 3.5.3 (2019-03-11)
Though when I try to run my script using this location of Rscript I get the same error that I did when running it using R 3.6. However, once I reinstalled R 3.5.3 the script ran fine.
Basically, I think somehow the most recently installed version of R seems to override and run no matter what I do to try and insure that an older version runs instead. Can someone help me piece together how or why this is happening, or provide a suggestion as to how to install R 3.6 as the default "R" while still allowing me to run 3.5.3 for certain scripts as needed?
I have similar problem. What you observed is clearly mentioned on https://cran.rstudio.org/doc/manuals/R-admin.html#Uninstalling-under-macOS: "However, R.APP will always run the ‘current’ version, that is the last installed version.". So far, I don't know how to solve the problem either. Using Rswitch worked very well to switch R versions manually, but i don't know how to integrate Rswitch to command lines.
I'm unable to install Boom 0.9 on Ubuntu 18.04, Boom 0.8 installs without issue. However, we need 0.9 as a pre-req for CausalImpact.
g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-7/README.Bugs> for instructions.
/usr/lib/R/etc/Makeconf:176: recipe for target 'Models/Glm/PosteriorSamplers/fill_poisson_mixture_approximation_table_2.o' failed
make[1]: *** [Models/Glm/PosteriorSamplers/fill_poisson_mixture_approximation_table_2.o] Error 4
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/tmp/RtmpKl6J7B/R.INSTALL90e7ca998b2/Boom/src'
ERROR: compilation failed for package 'Boom'
* removing '/usr/local/lib/R/site-library/Boom'
The downloaded source packages are in
'/tmp/RtmpIk7UFT/downloaded_packages'
Warning message:
In install.packages("Boom") : installation of one or more packages failed,
probably 'Boom'
I've ensured that build-essential is up to date with the most current version available (and tried g++-8 as well).
I think someone else in your org may have already contacted me about this. We are mid-flight debugging.
Boom is a large package and can time out when building. The first thing to check is that you are able to build with multiple cores (i.e. you can pass the -j x flag to make).
As a diagnostic you can try building the package without involving R. Clone https://github.com/steve-the-bayesian/BOOM and build with either bazel (up to date) or make (not too far out of date). If this build succeeds then compare flags passed to the R build vs the native build.
To better understand where R is failing, download the Boom package from CRAN https://cran.r-project.org/src/contrib/Boom_0.9.1.tar.gz and try the following from the command line
R CMD CHECK Boom_0.9.1.tar.gz
This will probably fail, but it will generate a directory called Boom.Rcheck, which contains a file 00install.out containing all the compiler output.
It is suspicious that the build above fails on the poisson_mixture_approximation_table, which is a large file that might be overflowing your stack. Or that might be a coincidence.
Take a look at: https://cran.r-project.org/web/checks/check_results_Boom.html
The check page says 'GNU make' is a undeclared SystemRequirement.
Version: 0.9.1
Check: for GNU extensions in Makefiles
Result: NOTE
GNU make is a SystemRequirements.
Since your installation process also seems to fail at make[1] it might make sense to check if GNU make is installed.
The installation of the Boom package from source (also during the Docker build) can fail for several reasons:
low memory pro core
low stack size
timeout of the build process (possible)
We are currently using the following setup for Docker:
core: 4
memory: 8GB
We can use the following command to set the stack size to 16MB before starting the installation:
Docker:
RUN ulimit -s 16384 \
&& R -e 'install.packages("Boom");'
Linux:
ulimit -s 16384 \
&& R -e 'install.packages("Boom");'
Note: The stack size is an operating system-related configuration and can vary depending on the host operating system used.
Note: The command to install the boom package may be different for your application. We use for example packrat.
Similar issue: link
Does anyone have a link to clear instructions on how to install and configure the necessary latex packages to build R packages on a mac?
I have some scripts for building and checking R packages on a mac server. They seemed to work fine, but after upgrading to R 3.1.3, many of the packages started failing with
Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet, :
Running 'texi2dvi' on 'networkVignette.tex' failed.
Messages:
sh: /usr/local/bin/texi2dvi: No such file or directory
Calls: <Anonymous> -> texi2pdf -> texi2dvi
Execution halted
I found a thread which seemed to suggest I need a more recent version texinfo (5.2) than what is installed by default. And apparently I've I've got the wrong version installed in the wrong location?
which texi2pdf
/sw/bin/texi2pdf
texi2pdf --version
texi2pdf (GNU Texinfo 5.1) 5234
(same version is reported when running system('texi2pdf --version') in R )
This thread gives a link to a texinfo 5.2 source collection:
http://r.789695.n4.nabble.com/R-CMD-build-looking-for-texi2dvi-in-the-wrong-place-R-devel-td4701706.html
But I'm not familiar with installing executable from a tar.gz file on a mac. The R mac help pages I found suggest installing MacTex, which I tried but that didn't seem to help.
** Update: ** additional discussion of related problems on R-SIG-mac mailing list:
https://groups.google.com/forum/#!topic/r-sig-mac/xjyuFdl5Ezk
Update:
Here is where I'm currently at:
I removed my /sw directory to uninstall fink and all of its packages (couldn't figure out how to upgrade it)
installed homebrew
brew install texinfo installs version 5.2 the package,
but generates the message This formula is keg-only, which means it was not symlinked into /usr/local and actually installs in in /usr/local/Cellar/texinfo/5.2/bin which means it is not on the path and R won't find it.
manually symlink each of the texi2pdf, texi2dvi , etc as vincent suggests (this is because R has the /usr/local/bin location as default in the tools::texi2dvi function?
edited the /etc/paths file on the system to add /usr/local/bin so that finds the brew installed 5.2 version before it finds it before the osx system supplied version 4.6 version. This may not be necessary because R has it hardcoded?
All of this gets rid of the "can't find texi* errors", and gives me a bunch of latex errors (which I don't see on unix and windows builds) so I'm still kind of stuck.
This seems very hackish, so there must be a cleaner way? But it sounds like stuff with tex and mac is very sketchy at the moment? https://tex.stackexchange.com/questions/208181/why-did-my-tex-related-gui-program-stop-working-in-mac-os-x-yosemite
This worked for me on Mavericks and on Yosemite:
ln -s /usr/bin/texi2dvi /usr/local/bin/texi2dvi
ln -s /usr/bin/texi2pdf /usr/local/bin/texi2pdf
On my Lion system both the command which texi2pdf at a Terminal/bash prompt and from a R.app GUI prompt tell me that I have that program in:
system("which texi2pdf")
#/opt/local/bin/texi2pdf
That is a location typical for MacPorts installation. I think the /usr/local/bin/ is what the binary R version "expects". I'm not really that UNIX savvy, but I think the you can modify the PATH environment variable so that R will be able to find your installation. (Whether it will be compatible I cannot say since so much detail is missing from your question.) My Tex installation is MacTex, which I got from https://www.tug.org/mactex/. I admit to having a cobbled-together system:
system("echo $PATH")
# /opt/local/bin:/opt/local/sbin:/sw/bin:/sw/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/texbin:/usr/X11/bin:/usr/X11R6/bin
That gets set at the beginning of an R session because this is the first line in my .Rprofile-(invisible)file:
Sys.setenv(PATH="/opt/local/bin:/opt/local/sbin:/sw/bin:/sw/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/texbin:/usr/X11/bin:/usr/X11R6/bin")
I think /sw/bin/ installations signify a fink install, which I have had very little success with. Simon Urbanek suggests not using any package installers, but then leaves the rest of us UNIX weenies very little in the way of worked examples of how to install that various external packages that underpin the many interesting and oh-so-useful R packages. So I feel your pain, but I'm not running for President.
So I suppose you could try this at your R console before again attempting one of the earlier unsuccessful installs:
Sys.setenv(PATH=paste( Sys.getenv()$PATH, # should be the character string of the $PATH
"/sw/bin/", sep=":")
)
Wish I could offer guarantees, but if it breaks the only guarantee is that you get to keep all the pieces.
I ran into a similar error message using Mavericks 10.9.5 (factory configured) and R 3.1.
It turns out that I didn't have pdfLaTex. I went to this page: http://tug.org/mactex/ and downloaded the MacTex installation package. It's big (>2GB) but after I installed it, my R package build problems went away.
Hope this might be helpful to anyone else who runs into this error message.