I'm working on Lispworks 8.0.1, and using the Common SQL interface provided by the software.
On the other hand I'm working with PostgreSQL and I want to connect a PostgreSQL database in LispWorks.
Here are the lines I use (following the lispworks guidelines) and the Common SQL tutorial:
(load-all-patches)
(require "postgresql")
(sql:initialize-database-type :database-type :postgresql)
The first two lines work perfectly but on the third line I get the following error :
Could not register handle for external module "-lpq" : dlopen(libpq, 0x0005): tried: 'libpq'
(relative path not allowed in hardened program),
'/System/Volumes/Preboot/Cryptexes/OSlibpq' (no such file), '/usr/lib/libpq' (no such file,
not in dyld cache), 'libpq' (relative path not allowed in hardened program), '/usr/lib/libpq'
(no such file, not in dyld cache).
I downloaded libqp through homebrew and also it is well written in the documentation that
For database-type :oracle, :mysql and :postgresql, if the client library is not installed in a standard place, its directory must be added to the environment variable DYLD_LIBRARY_PATH (see the OS manual entry for dyld).
so I configured the DYLD_LIBRARY_PATH in the .bash_profile file
export DYLD_LIBRARY_PATH=${DYLD_LIBRARY_PATH}:/opt/homebrew/Cellar/libpq
It didn't work so I tried with the .zshrc file the following line:
export DYLD_LIBRARY_PATH="/opt/homebrew/Cellar/libpq"
The error is still the same.
So, does anyone have encountered the same problem and/or has an idea how I can solve this?
Thanks
Related
I am running CoqIDE to use read the textbook series "Software Foundations", I am currently reading the volume "Logical Foundations". I just started Chapter 2 (Induction), but when I try to run the line
From LF Require Import Basics.
I get an error statement
The file ...\LF\Basics.vo contains library
Basics and not library LF.Basics
I tried renaming the directory the file was located in, and recompiled the buffers, but neither of these actions helped. What Shoudl i do in order to solve this problem?
We've been improving the explanation in the soon-to-be-released new version of LF. Here is the relevant bit:
For the [Require Export] to work, Coq needs to be able to
find a compiled version of [Basics.v], called [Basics.vo], in a directory
associated with the prefix [LF]. This file is analogous to the [.class]
files compiled from [.java] source files and the [.o] files compiled from
[.c] files.
First create a file named [_CoqProject] containing the following line
(if you obtained the whole volume "Logical Foundations" as a single
archive, a [_CoqProject] should already exist and you can skip this step):
[-Q . LF]
This maps the current directory ("[.]", which contains [Basics.v],
[Induction.v], etc.) to the prefix (or "logical directory") "[LF]".
PG and CoqIDE read [_CoqProject] automatically, so they know to where to
look for the file [Basics.vo] corresponding to the library [LF.Basics].
Once [_CoqProject] is thus created, there are various ways to build
[Basics.vo]:
- In Proof General: The compilation can be made to happen automatically
when you submit the [Require] line above to PG, by setting the emacs
variable [coq-compile-before-require] to [t].
- In CoqIDE: Open [Basics.v]; then, in the "Compile" menu, click
on "Compile Buffer".
- From the command line: Generate a [Makefile] using the [coq_makefile]
utility, that comes installed with Coq (if you obtained the whole
volume as a single archive, a [Makefile] should already exist
and you can skip this step):
[coq_makefile -f _CoqProject *.v -o Makefile]
Note: You should rerun that command whenever you add or remove Coq files
to the directory.
Then you can compile [Basics.v] by running [make] with the corresponding
[.vo] file as a target:
[make Basics.vo]
All files in the directory can be compiled by giving no arguments:
[make]
Under the hood, [make] uses the Coq compiler, [coqc]. You can also
run [coqc] directly:
[coqc -Q . LF Basics.v]
But [make] also calculates dependencies between source files to compile
them in the right order, so [make] should generally be prefered over
explicit [coqc].
If you have trouble (e.g., if you get complaints about missing
identifiers later in the file), it may be because the "load path"
for Coq is not set up correctly. The [Print LoadPath.] command
may be helpful in sorting out such issues.
In particular, if you see a message like
[Compiled library Foo makes inconsistent assumptions over
library Bar]
check whether you have multiple installations of Coq on your machine.
It may be that commands (like [coqc]) that you execute in a terminal
window are getting a different version of Coq than commands executed by
Proof General or CoqIDE.
- Another common reason is that the library [Bar] was modified and
recompiled without also recompiling [Foo] which depends on it. Recompile
[Foo], or everything if too many files are affected. (Using the third
solution above: [make clean; make].)
One more tip for CoqIDE users: If you see messages like [Error:
Unable to locate library Basics], a likely reason is
inconsistencies between compiling things _within CoqIDE_ vs _using
[coqc] from the command line_. This typically happens when there
are two incompatible versions of [coqc] installed on your
system (one associated with CoqIDE, and one associated with [coqc]
from the terminal). The workaround for this situation is
compiling using CoqIDE only (i.e. choosing "make" from the menu),
and avoiding using [coqc] directly at all. *)
I have installed pycparser that parses C code.
Using pycparser I want to parse an open source project, namely PostgreSQL . However, during compilation it cannot found some header files, namely
pg_config_ext.h and pg_config_os.h.
While looking at the directory structure of PostgreSQL, I find that it does not have these header files. How to fix this issue?
These header files are generated from the respective .in files when configure is run.
This will allow conditional compilation depending on the operating system and its configuration.
To compile PostgreSQL, you need what is called a configured source tree in PostgreSQL jargon.
Also note that the build process is somewhat different on Windows, see the documentation for details.
SQLAPI++ has an unusual feature where you set a string to tell it where to find the ODBC shared library. In my case this is libtdsodbc.so, and my application actually links that library at build time, but at runtime this is not enough for SQLAPI++ to work.
My code is:
SAConnection conn;
conn.setOption("ODBC.LIBS") = "libtdsodbc.so";
conn.Connect("SERVER=...", "", "", SA_ODBC_Client);
ODBC.LIBS is documented like this:
Forces SQLAPI++ Library to use specified ODBC manager library.
The above code works if you set LD_LIBRARY_PATH to a directory containing libtdsodbc.so. But if you don't, Connect() fails:
libtdsodbc.so: cannot open shared object file: No such file or directory
DBMS API Library 'libtdsodbc.so' loading fails
This library is a part of DBMS client installation, not SQLAPI++
Make sure DBMS client is installed and
this required library is available for dynamic loading
Linux/Unix:
1) The directories in the user's LD_LIBRARY_PATH environment variable
2) The list of libraries cached in /etc/ld.so.cache
3) /usr/lib, followed by /lib
It works again if you set ODBC.LIBS to a full path rather than just a filename. But how can the application know which path?
My application (outside of SQLAPI++) finds libtdsodbc.so via its RUNPATH which is set at build time. This path is not a system path like /usr/lib. I'd like to have SQLAPI++ use the same library which is loaded in the application at runtime.
One idea is for the application to inspect its own RUNPATH, search for libtdsobc.so, and use that path. But this requires quite a bit of fiddly code to basically reimplement what ld.so already does.
I don't want to bake the path into the executable at build time separately from RUNPATH, because I sometimes edit RUNPATH before deployment (and then I'd need to edit two things).
Ideally I would like to tell SQLAPI++ to just use the library which is already loaded. I can figure this path out by running lsof -p PID | grep libtdsodbc.so but running shell commands from within the executable is not a good solution (and again I would rather not reimplement lsof).
You could either use dl_iterate_phdr (the link also includes a sample code which prints out lib names) or manually parse /proc/self/maps.
I try to install/run emacs on a Win7 64-bit machine after using it for years on a WinXP 32-bit machine and run into a problem I do not find any help for in the documentation or on the web.
Symptom:
when starting runemacs.exe for the first time it creates the file
*C:\Users\USER\My Documents.emacs.d*
as one would expect (for my administrator as well as for my user account)
and comes up operational
from the second start of runemacs.exe it breaks in the startup phase,
displaying the scratch buffer, ringing the warning bell and displaying in
bottom line the error:
File exists: c:/Users/USER/My Documents/.emacs.d/
buffer messages specifies:
make-directory: File exists: c:/Users/USER/My Documents/.emacs.d/
if runemacs was called with a file to open, i.e. because the file type was
associated with it and the file was opened to edit, the file is not open
and ready to be edited, but a file can be opened via the menu File->Open File...
but my configurations in the file
C:\Users\USER\My Documents.emacs
are not loaded
My goal:
I want to regain the way I used emacs on the old WinXP 32-bit system:
click a file associated with emacs, get it opened and ready for editing, get my configurations in .emacs loaded automatically, i.e. work with emacs seamlessly.
Checks done and failed attempts to fix this:
I tried the following newly downloded versions of emacs
emacs-23.4-bin-i386.zip
emacs-23.2-bin-i386.zip (the one I used on the WinXP)
I had the emacs directory containing the directory stucture (bin, etc, ...)
located at:
C:\Program Files (x86)\emacs-23.4\ (my preferred location)
C:\Emacs\emacs-23.4\
in the download directory, where I originally extracted it
My HOME variable points to:
C:\Users\USER\My Documents (default)
C:\Users\USER\My Documents\ (tried)
My PATH variable contains:
C:\Program Files (x86)\emacs-23.4\bin (default)
or the corresponding other locations which I tried
The ownership and permissions of my C:\Users\USER\My Documents.emacs.d
look OK:
owner is the USER (administrator or standard_user)
permissions grant Full Control
Having originally installed emacs to *C:\Program Files (x86)\emacs-23.4*
using the administrator account, I also tried to use user account installation
instead (to check for some non- obvious parameter/access permission not set
right if the admin account is uses for setup)
For the runemacs.exe executable I manually set the compatibility settings to
Windows XP (Service Pack 3)
default setting after unpacking: no compatibility setting enabled
I removed the private configuration file C:\Users\USER\My Documents.emacs
(inherited from my XP installation) to check whether it produces a screw-up
All that did not change a bit of the described symptom, i.e. either I screwed up
in testing the above and missed a particular setting which should work, or I am looking into the wrong direction...
It is still unclear to me whether this has anything to do with:
W7 64-bit vs. XP 32-bit
environmental parameter screw-up
emacs configuration (.emacs, .emacs.d) screw-up
general stupidity (of me ;-)
... and why is it has emacs a problem with it in the first place, that the .emacs.d directory already exists... That should be the standard case...
Any help and wisdom much appreciated.
First of all, nice question. The details and listing of what you've already tried is helpful.
Some points:
Don't have spaces in key paths (Emacs, and %HOME%). Generally, things work
fine. But when things break it's often hard to debug and trace back to the
fact that some package author didn't take spaces properly into account.
Set a HOME environment variable to your %USER_PROFILE%. Make it
%USER_PROFILE%/home if you must, but I use the former.
Start by running emacs without any customization.
runemacs -Q
When that works, add your customizations one at a time.
n.b. This answer is not relevant to the original question (which was about Windows), but may be useful to Unix users searching for this error message
You will get this error also if emacs does not have the correct permissions on the .emacs.d directory.
Check it
ls -ld $HOME/.emacs.d
And make sure the user you are running under has rwx permissions!
I got similar problems when I installed the new version of emacs on a new installation of the ubuntu 12.10. I get the problem fixed by chmod 777 .emacs.d, that is, as the previous post pointed out, the emacs does not have the access right to .emacs.d directory. Hope this help.
My exe depends on ntdll, user32 and kernel32. I save these dlls as a local copy and change the first letter as "V".
I then edit the exe's Import dll name as Vernel32.dll from kernel32. The application works fine by loading vernel32.dll in local space.
Next i edit the exe's import dll spec as vtdll as ntdll, the process loads vtdll from local, runs its code and throws an _stackhash exception on vtdll instructions.
I need this for developing my appliction to bundle all windows dependencies. Does any body have any idea, Why ntdll cant be run in local space.
No! You cannot try to replace ntdll. It is mapped by the kernel into every single process, probably before any of your code is even loaded. It has an intricate connection with the kernel. It knows all the correct system call numbers. Try using ntdll from NT 5.1 and it will crash on NT 6.1. ntdll hosts the system call entry and exit code. The kernel-user callback dispatcher code. The thread start function which the kernel knows the address of. The user exception dispatcher. The user APC handler. I could go on, but I won't.
I don't see why you're trying to "bundle" these DLLs with your program. There is no way a Windows install won't have these DLLs. And that's ZERO chance for ntdll.dll since I don't see how without the session manager and CSR you are going to run your program in the first place.
I find the idea to "bundle" system DLL as not a good idea.
First of all it is illegal to redistribute this DLLs together with your application. Seconds you should understand that a DLL can create some global objects and the usage of two copies of the same DLL (vtdll.dll and ntdll.dll) can not work. You don't wrote how you modified imports of the dlls. If you do it on the disk it is illegal and moreover it break the signature of the files (open file properties of any of the dlls and look at "Digital Signatures" tab).
If you do want to experiment with different copies of system dlls you can better use DLL redirection (see http://msdn.microsoft.com/en-us/library/ms682600.aspx) through creating of files with the name myapp.exe.local where myapp.exe is the name of your application. It can be required to delete some entries from HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs to do this. You should understand that your computer will run slowly after this and I recommend to make such experiments better inside a virtual machine which you can easy restore if it will be no more booted.
Thanks for the information. It helped me to do a research on it.
I am not bundling the dlls for my own application. I am doing it for existing applications to provide a windows cross platform independence solution.
I tried the dll redirection technique which you have posted, with all applications.
It works well with all dlls except NTdll and User32.dll
User32.dll:
It loads user32.dll from local space only and not kernel space. I confirmed it. But on executing its instructions, it results in the null address access exception (c0000005) with fault module name StackHash_5964
ntdll:
The application on booting, it loads ntdll from system32 and again loads ntdll from local space, which may cause the error as you said (global object sharing violation)
This happens only for ntdll and not for user32.dll.
Is there any way we can make load ntdll once(only form local space) and avoid the errors caused by user32.dll in local space.
I tried the references sent by you and here are the results.
User32.dll
I couldnot build user32.dll having these below functions.
IsThreadDesktopComposited = user33.IsThreadDesktopComposited,
User32InitializeImmEntry = user33.User32InitializeImmEntry
It produces a linker error (Unreolved external symbol "IsThreadDesktopComposited")
Hence i left 100 such functions out of 800 functions in user32.dll. The DLL was built finally.
I then placed the dll in local space along with user33.dll. On running the application, it says the 100 missed functions procedure entry points are not found.
Ntdll.dll
I tried removing known dlls. But its inacccesible for modify or delete operations. I could just read. I am the admin and ran regedit as administrator.
Is it possible to do such implementatipons for ntdll or user32.dll.
I guess, am coming with repeated times.
Thanks for all your help.
But, If you have any other ways or any suggestions you can make, that would be grateful