Re: Problem with differences with DLOPEN / DLSYM compared to ubuntu (16.04) / debian (stretch).

2017-09-20 Thread Brian Inglis 
On 2017-09-15 10:59, Jon Turney wrote:
> On 15/09/2017 17:07, cyg Simple wrote:
>> Please consider using an interleaving method of posting on this list.
>> Top posting is considered rude.
>>
>> On 9/15/2017 9:51 AM, Gary Schneir wrote:
>>> Thanks for the response but I am a little confused by it.  If Cygwin is
>>> supposed to provide POSIX API functionality and DLOPEN / DLSYM are
>>> supported in CYGWIN, then I shouldn't care about the underlying
>>> complexity or restrictions of running within the Windows environment and
>>> using DLLs.  The behavior should be the same as in other POSIX environments.
>>
>> You presented your case well and I was waiting on someone familiar with
>> the code to respond.  I'm not sure that would be Kaz, he was just trying
>> to be helpful from his experiences.  I agree with your surmise that
>> Cygwin should perform similar results as Linux in this case.
> 
> ...
> 
>>> If you are saying that I did not include some sort of
>>> __declspec(dllexport) directive in my code so that it can find my
>>> symbols, that is something else but you indicate that you think cygwin
>>> hides that complexity in shared libraries.
>>
>> Actually it would be binutils, regardless of Cygwin or MinGW, that is
>> trying to hide the complexity of needing to supply the
>> __declspec([export|import]) declarations.  The logic for that is a bit
>> confusing but if none is given then all symbols are exported.
> 
> You need to decorate the symbols you wish to be visible with '__attribute__
> ((dllexport))' or '__declspec(dllexport)' (MSVC syntax which is also supported
> by gcc)
> 
> See [1] for an example of this done portably
> 
> [1] https://gcc.gnu.org/wiki/Visibility
> 
> Alternatively, you can use the ld flag --export-all-symbols (cf. with the ELF
> option --export-dynamic, which I think you must be using to get the observed
> behaviour on linux) to make all symbols visible.
> 
> Taking your example, and making it compilable:
> 
> $ cat dlopen.cc
> #include 
> #include 
> #include 
> 
> void * handle, * symbol;
> const char * errorStr;
> 
> int main()
> {
>   /* get access to the executable's symbol table */
>   handle = dlopen(NULL, RTLD_LAZY);
>   errorStr = dlerror();
> 
>   if (errorStr)
>     {
>   std::clog << "dlopen error '" << errorStr << "'" << std::endl;
>     }
>   if (handle)
>     {
>   std::clog << "handle ok " << std::endl;
>     }
>   else
>     {
>   std::clog << "handle NULL " << std::endl;
>     }
> 
>   /* look up the from_string function */
>   symbol = dlsym(handle, "functionname");
>   errorStr = dlerror();
> 
>   if (symbol)
>     {
>   std::clog << "dlsym symbol ok " << std::endl;
>     }
>   else
>     {
>   std::clog << "dlsym symbol NULL " << std::endl;
>     }
>   if (errorStr)
>     {
>   std::clog << "dlsym error '" << errorStr << "'" << std::endl;
>     }
> }
> 
> extern "C" __attribute__ ((dllexport))
> void functionname()
> {
> }
> 
> $ g++ dlopen.cc -o dlopen
> 
> $ ./dlopen
> handle ok
> dlsym symbol ok

No really comparable as the OP example was in a .dll/.so.
You would have to make your main e.g test, build into a dll, and call from a
separate main program.

The issue appears to be that dlopen( NULL, ...) should work as if it was a
reference to the dll containing the call, not the main program.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Successfully perform backup but warning message

2017-09-20 Thread KC Chin 
Hi Marco,

Thank you for your reply.
I have contacted them yesterday, they tell me the problem could be solve by
updating cygwin in my window server 2012. I have research on google how to
install the cygwin and downloaded setup-x86_64.exe from
cygwin.com/install.html

I planned to install this later and use all the default setting. Just one
simple question, will the program required a restart once the
installation/uninstallation is finished.
And also, will it affect the window stability ?

Thank you. Hope to hear from you soon.

Regards,
KC.

2017年9月20日 上午12:29，"Marco Atzeri" 写道：

On 19/09/2017 16:59, KC Chin wrote:

> Hi,
>
> Below is the warning message from log file.
>
> Profile Saturday failed to execute.
>
> Execution log
> -
>1 [main] rsync 5484 find_fast_cwd: WARNING: Couldn't compute
> FAST_CWD pointer.
>


> Server : Window server 2012
> Software : DeltaCopy 64bit
>

Have you noted that
http://www.aboutmyip.com/AboutMyXApp/DeltaCopy.jsp
is not mentioning anything newer that Windows 7 ?

It seems they are not really updating the things.



All of the backup files copied but in the end of the log file showing
> that one or
> more errors were encountered. May I know how to get this solve ?
>

DeltaCopy is using an obsolete version of the cygwin1.dll
Tell them to update the software they are distributing.


Thank you.
>
> Regards,
> KC
>

Re: Problem with differences with DLOPEN / DLSYM compared to ubuntu (16.04) / debian (stretch).

2017-09-20 Thread Kaz Kylheku 

On 15.09.2017 06:51, Gary Schneir wrote:

Thanks for the response but I am a little confused by it.  If Cygwin is
supposed to provide POSIX API functionality and DLOPEN / DLSYM are
supported in CYGWIN, then I shouldn't care about the underlying
complexity or restrictions of running within the Windows environment 
and
using DLLs.  The behavior should be the same as in other POSIX 
environments.


I don't see this behavior on Linux.

This is a transcript from an Ubuntu 16.04 system:

$ txr
This is the TXR Lisp interactive listener of TXR 186.
Quit with :quit or Ctrl-D on empty line. Ctrl-X ? for cheatsheet.
1> (dlopen nil)
#
2> (dlsym *1 "cons")
#
3> (dlsym *1 "car")
#
4> (dlsym *1 "cdr")
#
5> (dlsym *1 "malloc")
#
6> (dlsym *1 "printf")
#

The external functions cons, car and cdr in the txr executable
(I assure everyone they are there) cannot be found by dlsym,
but malloc and printf in the linked C library are found.

I.e. the same issue you're having on Cygwin.

Cygwin aims for Linux compatibility more than POSIX. The motto
is "get that Linux feeling on Windows", after all.
It's splashed right below the Cygwin banner here:
https://cygwin.com/

Not finding the executable's own symbol with dlsym (unless
some special arrangements are made to dynamically export
the symbols) looks very much like a "Linux feeling"!

If we run "nm -D" on the executable to see what dynamic symbols
are provided, we find only "_init" and "_fini":

$ nm -D /usr/local/bin/txr | grep T
080fa3cc T _fini
0804a7a4 T _init

and, by golly, these *can* be found with dlsym on the
dlopen(NULL, ...) handle!

7> (dlsym *1 "_fini")
#
8> (dlsym *1 "_init")
#


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [ANNOUNCEMENT] [Updated] mingw64-{i686,x86_64} binutils, gcc (Test)

2017-09-20 Thread Steven Penny 

On Tue, 19 Sep 2017 16:14:32, Steven Penny wrote:

Looks like a Cmake error rather than GCC - thought you might like to know.
Cmake is inserting "-isystem" instead of "-I":


Looks like I spoke too soon - I think it is a GCC error. Using this file:

$ cat alfa.cpp
#include 
#include 
int main() {
 puts("hello world");
}

5.4.0 compiles without issue:

$ x86_64-w64-mingw32-g++ --version
x86_64-w64-mingw32-g++ (GCC) 5.4.0

$ x86_64-w64-mingw32-g++ \

-I /usr/x86_64-w64-mingw32/sys-root/mingw/include alfa.cpp


$ x86_64-w64-mingw32-g++ \

-isystem /usr/x86_64-w64-mingw32/sys-root/mingw/include alfa.cpp


However 6.3.0 only works in certain cases:

$ x86_64-w64-mingw32-g++ \

-I /usr/x86_64-w64-mingw32/sys-root/mingw/include alfa.cpp


$ x86_64-w64-mingw32-g++ \

-isystem /usr/x86_64-w64-mingw32/sys-root/mingw/include alfa.cpp

In file included from
/usr/lib/gcc/x86_64-w64-mingw32/6.3.0/include/c++/ext/string_conversions.h:41:0,
from /usr/lib/gcc/x86_64-w64-mingw32/6.3.0/include/c++/bits/basic_string.h:5402,
from /usr/lib/gcc/x86_64-w64-mingw32/6.3.0/include/c++/string:52,
from /usr/lib/gcc/x86_64-w64-mingw32/6.3.0/include/c++/stdexcept:39,
from /usr/lib/gcc/x86_64-w64-mingw32/6.3.0/include/c++/array:39,
from /usr/lib/gcc/x86_64-w64-mingw32/6.3.0/include/c++/tuple:39,
from /usr/lib/gcc/x86_64-w64-mingw32/6.3.0/include/c++/functional:55,
from alfa.cpp:2:
/usr/lib/gcc/x86_64-w64-mingw32/6.3.0/include/c++/cstdlib:75:25: fatal error:
 stdlib.h: No such file or directory
#include_next 

Now really "-I" and "-isystem" are not really needed for this example, because
that directory gets pulled in already - but it should work even with them
included. Also it is somewhat important that it do work even with the redundant
options included, because Cmake often dumps those options in with GCC commands.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Unable to use Cygwin RCS commands in Windows Emacs

2017-09-20 Thread cyg Simple 
On 9/20/2017 4:12 PM, Heinz Werner Kramski-Grote wrote:
> At some point in history, /usr/bin/co, /usr/bin/ci, /usr/bin/rlog etc. turned 
> from .exe into shell scripts, which are now wrappers for the main program 
> /usr/bin/rcs.exe. 
> 
> However, these shell scripts can not be called directly from a Windows 
> command 
> line and moreover can not be invoked by a Windows (not Cygwin) Emacs (25.2 
> currentlly).
> 

I suggest you ask your Windows Emacs support list.  They would have the
most users with suggestions.

-- 
cyg Simple

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Unable to use Cygwin RCS commands in Windows Emacs

2017-09-20 Thread Brian Inglis 
On 2017-09-20 14:12, Heinz Werner Kramski-Grote wrote:
> At some point in history, /usr/bin/co, /usr/bin/ci, /usr/bin/rlog etc. turned 
> from .exe into shell scripts, which are now wrappers for the main program 
> /usr/bin/rcs.exe. 
> 
> However, these shell scripts can not be called directly from a Windows 
> command 
> line and moreover can not be invoked by a Windows (not Cygwin) Emacs (25.2 
> currentlly).
> 
> Windows Emacs expects external Windows commands/binaries like co, ci, rlog, 
> etc.  to exist somewhere in the PATH. The commands to be invoked for version 
> control with RCS are hardcoded into "C:\Program Files\emacs-25.2\share\emacs
> \25.2\lisp\vc\vc-rcs.el" and can not be customized, as far as I know.
> 
> I tried to create wrapper scripts for Windows too (co.cmd, ci.cmd etc. -  
> basically just "c:\cygwin\bin\bash -c '/bin/%~n0 %*'"), which work to some 
> extend on the Windows command line, but mostly fail when invoked from Emacs' 
> version control functions.
> 
> The most recent native Windows port of RCS I could find is version 5.7 and 
> dates back to 1999. In addition, it uses filenames like "RCS/somefile" 
> instead 
> of the usual "RCS/somefile,v", so this does not look like a way to go either. 
> 
> I'm clueless now. Does someone successfully use Cygwin's RCS commands in 
> Windows Emacs? Is there still an older Cygwin RCS package around which 
> contains "real" co.exe, ci.exe etc.? 
> 
> Any help is greatly appreciated.

Tried creating shortcuts to the commands in $HOME/bin/, running C:\Cygwin\bin\sh
/bin/cmd %*, and adding $HOME/bin to the start of your Windows PATH?

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Unable to use Cygwin RCS commands in Windows Emacs

2017-09-20 Thread Heinz Werner Kramski-Grote 
At some point in history, /usr/bin/co, /usr/bin/ci, /usr/bin/rlog etc. turned 
from .exe into shell scripts, which are now wrappers for the main program 
/usr/bin/rcs.exe. 

However, these shell scripts can not be called directly from a Windows command 
line and moreover can not be invoked by a Windows (not Cygwin) Emacs (25.2 
currentlly).

Windows Emacs expects external Windows commands/binaries like co, ci, rlog, 
etc.  to exist somewhere in the PATH. The commands to be invoked for version 
control with RCS are hardcoded into "C:\Program Files\emacs-25.2\share\emacs
\25.2\lisp\vc\vc-rcs.el" and can not be customized, as far as I know.

I tried to create wrapper scripts for Windows too (co.cmd, ci.cmd etc. -  
basically just "c:\cygwin\bin\bash -c '/bin/%~n0 %*'"), which work to some 
extend on the Windows command line, but mostly fail when invoked from Emacs' 
version control functions.

The most recent native Windows port of RCS I could find is version 5.7 and 
dates back to 1999. In addition, it uses filenames like "RCS/somefile" instead 
of the usual "RCS/somefile,v", so this does not look like a way to go either. 

I'm clueless now. Does someone successfully use Cygwin's RCS commands in 
Windows Emacs? Is there still an older Cygwin RCS package around which 
contains "real" co.exe, ci.exe etc.? 

Any help is greatly appreciated.
   Heinz

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple