On Mar 5 10:08, Corinna Vinschen wrote:
> On Mar 5 09:05, Robert Mark wrote:
> > I fixed up the rights on Windows so I am admin now, /etc/fstab like so:
> > none / cygdrive binary,posix=0,user 0 0
>
> You don't have to run under an admin account. If the cygdrive prefix
> is marked as "user" /e
On Mar 5 09:05, Robert Mark wrote:
> Turns out it was my cygdrive mount was not being set properly. I was
> changing the cygdrive mount in my own .bash_profile (via "mount
> --change-cygdrive-prefix /") because at the time I was not admin of
> the computer and couldn't edit /etc/profile or /etc/fs
OK, I now know it has nothing to do with LD_LIBRARY_PATH - instead
it's a cygdrive prefix issue.
> 2009-12-07 11:48) and am having trouble running a windows commands
> that I use a lot as part of Cygwin. For example, when I use taskkill I
> get:
>
> /c/WINDOWS/system32/taskk
I
get:
/c/WINDOWS/system32/taskkill.exe: error while loading shared
libraries: ?: cannot open shared object file: No such file or
directory
I have read some posts from this list and seen discussion around
LD_LIBRARY_PATH being the path for DLLs. In my environment the
LD_LIBRARY_PATH variable is
c/WINDOWS/system32/taskkill.exe: error while loading shared
> libraries: ?: cannot open shared object file: No such file or
> directory
>
> I have read some posts from this list and seen discussion around
> LD_LIBRARY_PATH being the path for DLLs. In my environment the
> LD_LIBRARY_PAT
open shared object file: No such file or
directory
I have read some posts from this list and seen discussion around
LD_LIBRARY_PATH being the path for DLLs. In my environment the
LD_LIBRARY_PATH variable is not set. I try "export
LD_LIBRARY_PATH="$PATH" but that doesn't fix th
t;
> Now, at risk of stating that which you already know quite well:
>
> Using /usr/lib as the default LD_LIBRARY_PATH makes sense on *NIX
> platforms where the shared libraries are themselves in PREFIX/lib, and
> LD_LIBRARY_PATH is used not only by dlopen() but by ld.so for runtime
&
wd/filename. This effectlvely
> suppresses the Win32 default DLL search path in LoadLibrary, thus using
> either LD_LIBRARY_PATH, or /usr/lib. From a POSIX perspective it's
> wrong to rely on the default Win32 DLL load order in dlopen() and the
> behaviour of dlopen() in 1.5.25 wa
On Mar 19 04:31, Yaakov S wrote:
> With 1.7, dlopen() no longer automatically searches /usr/bin by default.
> This was definitely not the case with 1.5, but I don't see any mention
> of this in the release notes or ChangeLog. Am I missing something here?
The default path if L
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
With 1.7, dlopen() no longer automatically searches /usr/bin by default.
This was definitely not the case with 1.5, but I don't see any mention
of this in the release notes or ChangeLog. Am I missing something here?
Yaakov
-BEGIN PGP SIGNATU
On Nov 25 11:13, John Emmas wrote:
> - Original Message - From: "Corinna Vinschen"
> Sent: 25 November 2008 10:43
> Subject: Re: LD_LIBRARY_PATH
>>
>> $PATH is what you want and if you examine /bin resp. /usr/bin, you see
>> that Cygwin puts all s
- Original Message -
From: "Corinna Vinschen"
Sent: 25 November 2008 10:43
Subject: Re: LD_LIBRARY_PATH
$PATH is what you want and if you examine /bin resp. /usr/bin, you see
that Cygwin puts all shared libs there for the above reason. /lib resp.
/usr/lib only contain the s
r/lib/. This isn't
> happening for Cygwin and I'm finding that I need to copy the shared
> objects into /usr/bin/
>
> After googling, I found out that I might be able to set an envinronment
> variable called LD_LIBRARY_PATH. So I set it up and tried again - but
> unfortunately
ng that I need to copy the shared
objects into /usr/bin/
After googling, I found out that I might be able to set an envinronment
variable called LD_LIBRARY_PATH. So I set it up and tried again - but
unfortunately, without success... :-(
The only options I've tried so far are LD_LIBRAR
this issue is still un-resolved. Contrary to what
cgf says, dlopen doesn't care about LD_LIBRARY_PATH
while opening dependent DLLs of its argument. It opens
the DLL if the depedent DLLs are found in the $PATH.
Your keyword is dependent.
When one dll depends on another in windows, it
On Sun, May 29, 2005 at 07:09:50PM -0700, Sunil wrote:
>So, this issue is still un-resolved. Contrary to what
>cgf say, dlopen doesn't care about LD_LIBRARY_PATH
>while opening dependent DLLs of its argument. It opens
>the DLL if the depedent DLLs are found in the $PATH.
d
I am not sure why the last email didn't reach the
list, but here goes again.
this issue is still un-resolved. Contrary to what
cgf says, dlopen doesn't care about LD_LIBRARY_PATH
while opening dependent DLLs of its argument. It opens
the DLL if the depedent DLLs are found in the $PATH
So, this issue is still un-resolved. Contrary to what
cgf say, dlopen doesn't care about LD_LIBRARY_PATH
while opening dependent DLLs of its argument. It opens
the DLL if the depedent DLLs are found in the $PATH.
I think you meant if I do dlopen("c.dll",..) it will
tr
Hello,
If I set my LD_LIBRARY_PATH to .:/path/to/a.so
then I get Win32 error 126 when trying to load a.so using dlopen().
Removing the .: seems to work but will cwd always be searched first? (I
usually confirm this with "shared" in gdb under Linux but in Cygwin this
command works d
2/27/2003 +0100, you wrote:
hi folks,
I am currently using my JNI so/dll library under solaris, linux and
cygwin. with solaris and linux, no problem, I bind to it using
load(..) since the LD_LIBRARY_PATH is set. BUT, under cygwin/windows,
it does not work and I shall tell the absolute path when I
uld also checkout the excellent webpage on using JNI with Cygwin at:
http://www.inonit.com/cygwin/
Alan Thompson
At 12:28 PM 2/27/2003 +0100, you wrote:
hi folks,
I am currently using my JNI so/dll library under solaris, linux and cygwin.
with solaris and linux, no problem, I bind to it using load(
Ronald,
At 04:10 2003-02-27, Ronald Landheer-Cieslak wrote:
On Thu, 27 Feb 2003, gilles bourgeois wrote:
> hi folks,
>
> I am currently using my JNI so/dll library under solaris, linux and cygwin.
> with solaris and linux, no problem, I bind to it using load(..) since the
> LD_LIBR
On Thu, 27 Feb 2003, gilles bourgeois wrote:
> hi folks,
> I am currently using my JNI so/dll library under solaris, linux and cygwin.
> with solaris and linux, no problem, I bind to it using load(..) since the
> LD_LIBRARY_PATH is set.
> BUT, under cygwin/windows, it does not w
hi folks,
I am currently using my JNI so/dll library under solaris, linux and cygwin.
with solaris and linux, no problem, I bind to it using load(..) since the
LD_LIBRARY_PATH is set.
BUT, under cygwin/windows, it does not work and I shall tell the absolute
path when I load the library.
I hav
On Thu, Oct 31, 2002 at 11:22:00AM +0100, "Schn?rr, Claudius Dr." wrote:
>- the LD_LIBRARY_PATH is not searched for .dlls
LD_LIBRARY_PATH is only searched for dynamically loaded dlls.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http
At 05:22 AM 10/31/2002, Schnörr, Claudius Dr. wrote:
>Hello,
>
>I try to build some libraries, which in turn create *.so shared libraries.
>
>According to my tests,
>- names of shared libraries under cygwin have to end in .dll,
>- the LD_LIBRARY_PATH is not searched for .dl
Hello,
I try to build some libraries, which in turn create *.so shared libraries.
According to my tests,
- names of shared libraries under cygwin have to end in .dll,
- the LD_LIBRARY_PATH is not searched for .dlls
Is this correct?
Are there some workarounds to configure cygwin to behave like a
27 matches
Mail list logo
