Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #100020 > unrolled thread

altering winbase.h

Back to article view | Back to comp.lang.c

Contents

  altering winbase.h Michael Holiday <Mike@example.invalid> - 2016-12-21 21:54 -0800
    Re: altering winbase.h Michael Holiday <Mike@example.invalid> - 2016-12-21 22:40 -0800
      Re: altering winbase.h jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-22 09:24 +0100
        Re: altering winbase.h Michael Holiday <Mike@example.invalid> - 2016-12-22 02:37 -0800
          Re: altering winbase.h jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-22 18:12 +0100
      Re: altering winbase.h Michael Holiday <Mike@example.invalid> - 2016-12-22 02:31 -0800
        Re: altering winbase.h jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-22 18:17 +0100
          Re: altering winbase.h Michael Holiday <Mike@example.invalid> - 2016-12-25 01:29 -0800
            Re: altering winbase.h jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-25 11:58 +0100
              C tools for perl Michael Holiday <Mike@example.invalid> - 2017-01-26 23:30 -0800
          Re: altering winbase.h Keith Thompson <kst-u@mib.org> - 2016-12-25 12:17 -0800
            Re: altering winbase.h jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-25 22:46 +0100
              Re: altering winbase.h Keith Thompson <kst-u@mib.org> - 2016-12-25 15:17 -0800

#100020 — altering winbase.h

I have a C problem that has manifest itself thru the holidays as well as 
a wanton attack on territory I swore to defend in Berlin. I chose to 
renew my news policy from the free university, where they always said 
I'd be back. I loved paying valued taxes on the transaction about as 
much as I love Berlin.

I present with an implementation-specific compile problem. I should make 
a short post to see whether I'm actually making it thru to post source....
--
Mike

~~Das sind keere Erdbeeren.

[toc] | [next] | [standalone]

#100021

On 12/21/2016 9:54 PM, Michael Holiday wrote:
> I have a C problem that has manifest itself thru the holidays as well as
> a wanton attack on territory I swore to defend in Berlin. I chose to
> renew my news policy from the free university, where they always said
> I'd be back. I loved paying valued taxes on the transaction about as
> much as I love Berlin.
>
> I present with an implementation-specific compile problem. I should make
> a short post to see whether I'm actually making it thru to post source....
> --
> Mike
>
> ~~Das sind keere Erdbeeren.


C:\Users\Fred\Documents\Win32-LongPath-master\Win32-LongPath-master>dir
  Volume in drive C is Windows8_OS
  Volume Serial Number is 3052-CD20

  Directory of 
C:\Users\Fred\Documents\Win32-LongPath-master\Win32-LongPath-master

12/20/2016  03:18 PM    <DIR>          .
12/20/2016  03:18 PM    <DIR>          ..
12/20/2016  03:18 PM    <DIR>          blib
12/20/2016  03:14 PM             1,170 Changes
12/20/2016  03:14 PM    <DIR>          inc
12/20/2016  03:14 PM    <DIR>          lib
12/20/2016  03:18 PM                 0 LongPath.bs
12/20/2016  03:17 PM            35,108 Makefile
12/20/2016  03:14 PM             1,181 Makefile.PL
12/20/2016  03:14 PM               421 MANIFEST
12/20/2016  03:14 PM                41 MANIFEST.SKIP
12/20/2016  03:14 PM               877 META.yml
12/20/2016  03:17 PM             1,633 MYMETA.json
12/20/2016  03:17 PM               986 MYMETA.yml
12/20/2016  03:17 PM           203,218 ppport.h
12/20/2016  03:14 PM             2,389 README
12/20/2016  03:14 PM    <DIR>          t
12/20/2016  03:18 PM    <DIR>          xs
               11 File(s)        247,024 bytes
                7 Dir(s)  38,704,332,800 bytes free

C:\Users\Fred\Documents\Win32-LongPath-master\Win32-LongPath-master>dmake 
install
cp lib/Win32/LongPath.pm blib\lib\Win32\LongPath.pm
"C:\Strawberry\perl\bin\perl.exe" "-Iinc" -MExtUtils::Command::MM -e 
cp_nonempty -- LongPath.bs blib\arch\auto\Win32\LongPath\LongPath.bs 644
gcc -c  "-I." "-I."     -s -O2 -DWIN32 -DWIN64 -DCONSERVATIVE 
-DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS 
-fwrapv -fno-strict-aliasing -mms-bitfields -Wall -W -Wno-comment -s -O2 
       -DVERSION=\"1.07\"    -DXS_VERSION=\"1.07\" -o xs\LongPath.o 
"-IC:\STRAWB~1\perl\lib\CORE"  -DUSE_PPPORT -DWINVER=0x0a00 
-D_WIN32_WINNT=0x0a00 xs\LongPath.c
In file included from C:/STRAWB~1/perl/lib/CORE/hv.h:631,
                  from C:/STRAWB~1/perl/lib/CORE/perl.h:3904,
                  from xs\\LongPath.xs:21:
C:/STRAWB~1/perl/lib/CORE/hv_func.h: In function `S_perl_hash_murmur3':
C:/STRAWB~1/perl/lib/CORE/hv_func.h:403: warning: cast from pointer to 
integer of different size
xs\\LongPath.xs: In function `MakeSymbolicLink':
xs\\LongPath.xs:79: warning: implicit declaration of function 
`CreateSymbolicLinkW'
xs\\LongPath.xs:80: error: `SYMBOLIC_LINK_FLAG_DIRECTORY' undeclared 
(first use in this function)
xs\\LongPath.xs:80: error: (Each undeclared identifier is reported only once
xs\\LongPath.xs:80: error: for each function it appears in.)
xs\\LongPath.xs: In function `XS_Win32__LongPath_find_close':
xs\\LongPath.xs:179: warning: cast to pointer from integer of different size
xs\\LongPath.xs: In function `XS_Win32__LongPath_find_first_file':
xs\\LongPath.xs:191: warning: cast from pointer to integer of different size
xs\\LongPath.xs: In function `XS_Win32__LongPath_find_next_file':
xs\\LongPath.xs:281: warning: cast to pointer from integer of different size
dmake.exe:  Error code 129, while making 'xs\LongPath.o'

--

mike

[toc] | [prev] | [next] | [standalone]

#100022

You are using the wrong SDK headers. Your machine is misconfigured: it 
is using windows headers for windows xp

[toc] | [prev] | [next] | [standalone]

#100025

On 12/22/2016 12:24 AM, jacobnavia wrote:
> You are using the wrong SDK headers. Your machine is misconfigured: it
> is using windows headers for windows xp

Can you elaborate? (this is windows 10)
-- 
Mike

[toc] | [prev] | [next] | [standalone]

#100040

Le 22/12/2016 à 11:37, Michael Holiday a écrit :
> On 12/22/2016 12:24 AM, jacobnavia wrote:
>> You are using the wrong SDK headers. Your machine is misconfigured: it
>> is using windows headers for windows xp
>
> Can you elaborate? (this is windows 10)

Yes, the system is windows 10, but the include headers for the stuff you 
are compiling where do they came from?

You can run windows 10 and download the SDK for windows xp and if you 
use that, you will NOT find all the necessary functions or defines.

It could be also that you are using gcc under windows, what is never a 
good idea, and that gcc has old headers that do not include many things 
that the windows headers need.

Question:

Where do you got those include files?

[toc] | [prev] | [next] | [standalone]

#100024

On 12/21/2016 10:40 PM, Michael Holiday wrote:

> C:\Users\Fred\Documents\Win32-LongPath-master\Win32-LongPath-master>dmake install
>
> cp lib/Win32/LongPath.pm blib\lib\Win32\LongPath.pm
> "C:\Strawberry\perl\bin\perl.exe" "-Iinc" -MExtUtils::Command::MM -e
> cp_nonempty -- LongPath.bs blib\arch\auto\Win32\LongPath\LongPath.bs 644
> gcc -c  "-I." "-I."     -s -O2 -DWIN32 -DWIN64 -DCONSERVATIVE
> -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS
> -fwrapv -fno-strict-aliasing -mms-bitfields -Wall -W -Wno-comment -s -O2
>       -DVERSION=\"1.07\"    -DXS_VERSION=\"1.07\" -o xs\LongPath.o
> "-IC:\STRAWB~1\perl\lib\CORE"  -DUSE_PPPORT -DWINVER=0x0a00
> -D_WIN32_WINNT=0x0a00 xs\LongPath.c
> In file included from C:/STRAWB~1/perl/lib/CORE/hv.h:631,
>                  from C:/STRAWB~1/perl/lib/CORE/perl.h:3904,
>                  from xs\\LongPath.xs:21:
> C:/STRAWB~1/perl/lib/CORE/hv_func.h: In function `S_perl_hash_murmur3':
> C:/STRAWB~1/perl/lib/CORE/hv_func.h:403: warning: cast from pointer to
> integer of different size
> xs\\LongPath.xs: In function `MakeSymbolicLink':
> xs\\LongPath.xs:79: warning: implicit declaration of function
> `CreateSymbolicLinkW'
> xs\\LongPath.xs:80: error: `SYMBOLIC_LINK_FLAG_DIRECTORY' undeclared
> (first use in this function)
> xs\\LongPath.xs:80: error: (Each undeclared identifier is reported only
> once
> xs\\LongPath.xs:80: error: for each function it appears in.)
> xs\\LongPath.xs: In function `XS_Win32__LongPath_find_close':
> xs\\LongPath.xs:179: warning: cast to pointer from integer of different
> size
> xs\\LongPath.xs: In function `XS_Win32__LongPath_find_first_file':
> xs\\LongPath.xs:191: warning: cast from pointer to integer of different
> size
> xs\\LongPath.xs: In function `XS_Win32__LongPath_find_next_file':
> xs\\LongPath.xs:281: warning: cast to pointer from integer of different
> size
> dmake.exe:  Error code 129, while making 'xs\LongPath.o'
>

This started out as a perl question, but is ready to die of neglect at 
the bottom of a thread. It is, essentially OT there now that it's taken 
quite the C turn:

http://www.perlmonks.org/?node_id=1178277

I was advised to define SYMBOLIC_LINK_FLAG_DIRECTORY . I ran the result 
with the same litany of errors then defined it to be 1 with the same 
result. What I seek is the command to reveal what is defined before 
compilation on the gcc implementation used by contemporary perl.
--

[toc] | [prev] | [next] | [standalone]

#100042

Add this to winbase.h
BOOLEAN WINAPI CreateSymbolicLink(LPTSTR lpSymlinkFileName,
   LPTSTR lpTargetFileName,
    DWORD  dwFlags
);

#define SYMBOLIC_LINK_FLAG_DIRECTORY 1

[toc] | [prev] | [next] | [standalone]

#100232

On 12/22/2016 9:17 AM, jacobnavia wrote:
> Add this to winbase.h
> BOOLEAN WINAPI CreateSymbolicLink(LPTSTR lpSymlinkFileName,
>   LPTSTR lpTargetFileName,
>    DWORD  dwFlags
> );
>
> #define SYMBOLIC_LINK_FLAG_DIRECTORY 1

I made the change you suggested to the one of 2 winbase.h 's on this 
machine, the one I think is relevant:

Directory of C:\Perl\site\lib\auto\MinGW\include
...
12/22/2016  11:34 PM           102,458 winbase.h
...
C:\Perl\site\lib\auto\MinGW\include>type winbase.h
BOOLEAN WINAPI CreateSymbolicLink(LPTSTR lpSymlinkFileName,
   LPTSTR lpTargetFileName,
    DWORD  dwFlags
);

#define SYMBOLIC_LINK_FLAG_DIRECTORY 1

and I think I get farther with build. The way I see I see it is that the 
warnings from the C part turn into errors on the following, g++ step.

C:\Users\Fred\Documents\Win32-LongPath-master\Win32-LongPath-master>dmake
...
gcc ...\LongPath.c
In file included from C:/STRAWB~1/perl/lib/CORE/hv.h:631,
                  from C:/STRAWB~1/perl/lib/CORE/perl.h:3904,
                  from xs\\LongPath.xs:21:
C:/STRAWB~1/perl/lib/CORE/hv_func.h: In function `S_perl_hash_murmur3':
C:/STRAWB~1/perl/lib/CORE/hv_func.h:403: warning: cast from pointer to 
integer of different size
xs\\LongPath.xs: In function `MakeSymbolicLink':
xs\\LongPath.xs:79: warning: implicit declaration of function 
`CreateSymbolicLinkW'
xs\\LongPath.xs: In function `XS_Win32__LongPath_find_close':
xs\\LongPath.xs:179: warning: cast to pointer from integer of different size
... 2 more similar warnings
g++ LongPath.def -o blib\arch\auto\Win32\LongPath\LongPath.xs.dll -mdll 
-s -L"C:\STRAWB~1\perl\lib\CORE" -L"C:\STRAWB~1\c\lib" -static-libgcc 
-static-libstdc++ xs/LongPath.o 
"C:\STRAWB~1\perl\lib\CORE\libperl524.a" -lmoldname -lkernel32 -luser32 
-lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 
-lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 
-lcomctl32 -Wl,--enable-auto-image-base
g++.exe: unrecognized option `-static-libstdc++'
xs/LongPath.o:LongPath.c:(.text+0xef): undefined reference to 
`_imp__Perl_sv_2pv_flags'
... 100 similar lines
xs/LongPath.o:LongPath.c:(.text+0x2c76): undefined reference to 
`_imp__Perl_xs_boot_epilog'
collect2: ld returned 1 exit status
dmake.exe:  Error code 129, while making 
'blib\arch\auto\Win32\LongPath\LongPath.xs.dll'

C:\Users\Fred\Documents\Win32-LongPath-master\Win32-LongPath-master>

I thought I might try to find a windows sdk for windows 10, and 
downloaded something that took an hour to install without moving the 
needle on this. So I'm stuck, and this doesn't even seem to be a C 
question anymore, so I'm ready to move on unless someone has a bright 
idea or an average one that I've missed.

Merry Xmas
-- 
Michael

[toc] | [prev] | [next] | [standalone]

#100234

All API functions that take character strings have two entry points:

ApinameW
ApinameA

Where the 'W' means wide character set, and 'A' MEANS ASCII

Then you have to add
#ifdef UNICODE
#define Apiname ApinameW
#else
#define Apiname ApinameA
#endif

In this case

BOOLEAN WINAPI CreateSymbolicLinkW(LPWSTR lpSymlinkFileName,
    LPWSTR lpTargetFileName,
     DWORD  dwFlags
  );

BOOLEAN WINAPI CreateSymbolicLinkA(LPSTR lpSymlinkFileName,
    LPSTR lpTargetFileName,
     DWORD  dwFlags
  );

#ifdef UNICODE
#define CreateSymbolicLink CreateSymbolicLinkW
#else
#define CreateSymbolicLink CreateSymbolicLinkA
#endif


Le 25/12/2016 à 10:29, Michael Holiday a écrit :
> On 12/22/2016 9:17 AM, jacobnavia wrote:
>> Add this to winbase.h
>> BOOLEAN WINAPI CreateSymbolicLink(LPTSTR lpSymlinkFileName,
>>   LPTSTR lpTargetFileName,
>>    DWORD  dwFlags
>> );
>>
>> #define SYMBOLIC_LINK_FLAG_DIRECTORY 1
>
> I made the change you suggested to the one of 2 winbase.h 's on this
> machine, the one I think is relevant:
>
> Directory of C:\Perl\site\lib\auto\MinGW\include
> ...
> 12/22/2016  11:34 PM           102,458 winbase.h
> ...
> C:\Perl\site\lib\auto\MinGW\include>type winbase.h
> BOOLEAN WINAPI CreateSymbolicLink(LPTSTR lpSymlinkFileName,
>   LPTSTR lpTargetFileName,
>    DWORD  dwFlags
> );
>
> #define SYMBOLIC_LINK_FLAG_DIRECTORY 1
>
> and I think I get farther with build. The way I see I see it is that the
> warnings from the C part turn into errors on the following, g++ step.
>
> C:\Users\Fred\Documents\Win32-LongPath-master\Win32-LongPath-master>dmake
> ...
> gcc ...\LongPath.c
> In file included from C:/STRAWB~1/perl/lib/CORE/hv.h:631,
>                  from C:/STRAWB~1/perl/lib/CORE/perl.h:3904,
>                  from xs\\LongPath.xs:21:
> C:/STRAWB~1/perl/lib/CORE/hv_func.h: In function `S_perl_hash_murmur3':
> C:/STRAWB~1/perl/lib/CORE/hv_func.h:403: warning: cast from pointer to
> integer of different size
> xs\\LongPath.xs: In function `MakeSymbolicLink':
> xs\\LongPath.xs:79: warning: implicit declaration of function
> `CreateSymbolicLinkW'

There isn't any proto for this, so it is assumed by default "int"
and the compiler warns since an int can't hold a pointer

> xs\\LongPath.xs: In function `XS_Win32__LongPath_find_close':
> xs\\LongPath.xs:179: warning: cast to pointer from integer of different
> size
> ... 2 more similar warnings
> g++ LongPath.def -o blib\arch\auto\Win32\LongPath\LongPath.xs.dll -mdll
> -s -L"C:\STRAWB~1\perl\lib\CORE" -L"C:\STRAWB~1\c\lib" -static-libgcc
> -static-libstdc++ xs/LongPath.o "C:\STRAWB~1\perl\lib\CORE\libperl524.a"
> -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32
> -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm
> -lversion -lodbc32 -lodbccp32 -lcomctl32 -Wl,--enable-auto-image-base
> g++.exe: unrecognized option `-static-libstdc++'
> xs/LongPath.o:LongPath.c:(.text+0xef): undefined reference to
> `_imp__Perl_sv_2pv_flags'
> ... 100 similar lines

This meazns that the library that contains "Perl_sv_2pv_flags" is not 
included in the link, or you are using an older version of that import 
library that doesn't contain that symbol. Verify your perl import libraries.

> xs/LongPath.o:LongPath.c:(.text+0x2c76): undefined reference to
> `_imp__Perl_xs_boot_epilog'
> collect2: ld returned 1 exit status
> dmake.exe:  Error code 129, while making
> 'blib\arch\auto\Win32\LongPath\LongPath.xs.dll'
>
> C:\Users\Fred\Documents\Win32-LongPath-master\Win32-LongPath-master>
>
> I thought I might try to find a windows sdk for windows 10, and
> downloaded something that took an hour to install without moving the
> needle on this.

Yes, that will not work since you are not using the SDK you downloaded 
beacause you are using gcc, and you did not generate again the include 
files.

As you know:
                 NO WARRANTY

   11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO
WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR
OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND,
EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS
WITH YOU.  SHOULD THE  PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

[toc] | [prev] | [next] | [standalone]

#102512 — C tools for perl

On 12/25/2016 2:58 AM, jacobnavia wrote:

[OP snips, updates subject]

>> xs\\LongPath.xs: In function `XS_Win32__LongPath_find_close':
>> xs\\LongPath.xs:179: warning: cast to pointer from integer of different
>> size
>> ... 2 more similar warnings
>> g++ LongPath.def -o blib\arch\auto\Win32\LongPath\LongPath.xs.dll -mdll
>> -s -L"C:\STRAWB~1\perl\lib\CORE" -L"C:\STRAWB~1\c\lib" -static-libgcc
>> -static-libstdc++ xs/LongPath.o "C:\STRAWB~1\perl\lib\CORE\libperl524.a"
>> -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32
>> -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm
>> -lversion -lodbc32 -lodbccp32 -lcomctl32 -Wl,--enable-auto-image-base
>> g++.exe: unrecognized option `-static-libstdc++'
>> xs/LongPath.o:LongPath.c:(.text+0xef): undefined reference to
>> `_imp__Perl_sv_2pv_flags'
>> ... 100 similar lines
>
> This [means] that the library that contains "Perl_sv_2pv_flags" is not
> included in the link, or you are using an older version of that import
> library that doesn't contain that symbol. Verify your perl import
> libraries.

I've done my best with this, including ripping out everything I had and 
replacing it anew. Perl scripts work, but C doesn't link. Ian (Collins) 
advises that the following is relevant:

C:\Users\Fred\Documents>gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=C:/Strawberry/c/bin/../libexec/gcc/x86_64-w64-mingw32/4.9.2/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-4.9.2/configure 
--host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 
--target=x86_64-w64-mingw32 --prefix=/mingw64 
--with-gxx-include-dir=/mingw64/x86_64-w64-mingw32/include/c++ 
--enable-shared --enable-static --disable-multilib 
--enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes 
--enable-threads=posix --enable-libgomp --enable-libatomic --enable-lto 
--enable-graphite --enable-checking=release 
--enable-fully-dynamic-string --enable-version-specific-runtime-libs 
--enable-sjlj-exceptions --disable-isl-version-check 
--disable-cloog-version-check --disable-libstdcxx-pch 
--disable-libstdcxx-debug --disable-bootstrap --disable-rpath 
--disable-win32-registry --disable-nls --disable-werror 
--disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona 
--with-tune=core2 --with-libiconv --with-system-zlib 
--with-gmp=/opt/build/prerequisites/x86_64-w64-mingw32-static 
--with-mpfr=/opt/build/prerequisites/x86_64-w64-mingw32-static 
--with-mpc=/opt/build/prerequisites/x86_64-w64-mingw32-static 
--with-isl=/opt/build/prerequisites/x86_64-w64-mingw32-static 
--with-cloog=/opt/build/prerequisites/x86_64-w64-mingw32-static 
--enable-cloog-backend=isl --with-pkgversion='x86_64-posix-sjlj, built 
by strawberryperl.com project' CFLAGS='-O2 -pipe 
-I/opt/build/x86_64-492-posix-sjlj-rt_v402/mingw64/opt/include 
-I/opt/build/prerequisites/x86_64-zlib-static/include 
-I/opt/build/prerequisites/x86_64-w64-mingw32-static/include' 
CXXFLAGS='-O2 -pipe 
-I/opt/build/x86_64-492-posix-sjlj-rt_v402/mingw64/opt/include 
-I/opt/build/prerequisites/x86_64-zlib-static/include 
-I/opt/build/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS= 
LDFLAGS='-pipe 
-L/opt/build/x86_64-492-posix-sjlj-rt_v402/mingw64/opt/lib 
-L/opt/build/prerequisites/x86_64-zlib-static/lib 
-L/opt/build/prerequisites/x86_64-w64-mingw32-static/lib '
Thread model: posix
gcc version 4.9.2 (x86_64-posix-sjlj, built by strawberryperl.com project)

C:\Users\Fred\Documents>

At the outside, this is two weeks old. We've had something called a 
pineapple express flatten our fair metropolis, which is why I decided to 
deal with the C aspects of this, and perl is C just right under the 
hood. I like that about being a perl, because I know it's going to 
resolve to C at some point.

C:\Users\Fred\Documents>gcc deque.c
C:\Users\Fred\AppData\Local\Temp\ccEXIKGX.o:deque.c:(.text+0x8e): 
undefined reference to `DLAddBefore'
...
C:\Users\Fred\AppData\Local\Temp\ccEXIKGX.o:deque.c:(.text+0x63a): 
undefined reference to `DLDestroy'
C:/Strawberry/c/bin/../lib/gcc/x86_64-w64-mingw32/4.9.2/../../../../x86_64-w64-mingw32/lib/../lib/libmingw32.a(lib64_libmingw32_a-crt0_c.o):crt0_c.c:(.text.startup+0x25): 
undefined reference to `WinMain'
collect2.exe: error: ld returned 1 exit status

I'm frankly embarrassed by this. It was much easier to have MS's 
development tools whilst working on windows. Linking happens magically, 
with glitz and splendor. Cross-compilation is fraught.

BartC asks us whether we're programmers. I'm not, unless I have a C 
compiler that I can query through standard C, which, I assume 
heathfield's program is.

There will be a name collision on the word "library." Perl has this 
notion of a lib as a directory where files are found. In this 
implementation, it follows the -l notion.

Can someone tell me what this means?

CPPFLAGS= LDFLAGS='-pipe 
-L/opt/build/x86_64-492-posix-sjlj-rt_v402/mingw64/opt/lib 
-L/opt/build/prerequisites/x86_64-zlib-static/lib 
-L/opt/build/prerequisites/x86_64-w64-mingw32-static/lib '

 > Verify your perl import libraries.

Have I done so?
-- 
Michael Holiday

[toc] | [prev] | [next] | [standalone]

#100274

jacobnavia <jacob@jacob.remcomp.fr> writes:
> Add this to winbase.h
> BOOLEAN WINAPI CreateSymbolicLink(LPTSTR lpSymlinkFileName,
>    LPTSTR lpTargetFileName,
>     DWORD  dwFlags
> );
>
> #define SYMBOLIC_LINK_FLAG_DIRECTORY 1

Disclaimer: I don't know what winbase.h is.

If it's provided by the OS or by some installable package
(another followup suggests that it's part of a Perl installation,
in C:\Perl\site\lib\auto\MinGW\include), then modifying it is
unlikely to be the best solution.  It might fix your own build
problem but if your application's source code depends on a change
to some system header it's going to be a real portability problem.

Instead, I'd suggest adding that declaration somewhere in your own
application's source code.

And if that's a missing declaration that *should* be in that header,
consider reporting the problem to the provider of that header file.
There's no winbase.h in the Perl source tree.  Perhaps it's provided
by some third party, likely Strawberry or ActiveState.

Upthread, Michael Holiday wrote:

    I was advised to define SYMBOLIC_LINK_FLAG_DIRECTORY . I ran
    the result with the same litany of errors then defined it to be
    1 with the same result. What I seek is the command to reveal
    what is defined before compilation on the gcc implementation
    used by contemporary perl.

Did you define that macro *before* the relevant #include
directive(s)?

If you mean you want to see the output of the preprocessor, you can use
"gcc -E".

I'll note again that I don't know what winbase.h is or who
provides it.  I'm making assumptions based on the directory path.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#100275

Le 25/12/2016 à 21:17, Keith Thompson a écrit :
> I don't know what winbase.h is or who
> provides it.  I'm making assumptions based on the directory path.

winbase.h is one of the principal include files of windows provided by 
the Micorosft SDK. That is why I spoke about the SDK in my answers, that 
you ignore. That is why I told him to get a correct SDK.

[toc] | [prev] | [next] | [standalone]

#100277

jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 25/12/2016 à 21:17, Keith Thompson a écrit :
>> I don't know what winbase.h is or who
>> provides it.  I'm making assumptions based on the directory path.
>
> winbase.h is one of the principal include files of windows provided by 
> the Micorosft SDK. That is why I spoke about the SDK in my answers, that 
> you ignore. That is why I told him to get a correct SDK.

I see you said something about that in another article, which I hadn't
read closely.  In the post I replied to, all you said was:

    Add this to winbase.h
    BOOLEAN WINAPI CreateSymbolicLink(LPTSTR lpSymlinkFileName,
      LPTSTR lpTargetFileName,
       DWORD  dwFlags
    );
    
    #define SYMBOLIC_LINK_FLAG_DIRECTORY 1

Is modifying a header file that's provided by the Microsoft SDK,
as you advised, considered to be a good idea?  I wouldn't have
thought so.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web