C / C++ / MFC

Solution access internet by proxy server c++

17-Sep-17 21:45

Your NODE class does not initialise the next and previous members in the constructor. You are initialising them in your DoublyLinkedList class when adding a node. But so valid states depend on that which is dangerous and bad style. You should initialise them in the constructor to ensure that they contain always a defined value.

You are allocating your objects on the stack but in DeleteNODE you call delete. Sou you should allocate them on the heap instead:

NODE *obj1 = new NODE("Dragu", "Stelian", "1911226284570", "dragu_stelian@yahoo.com");
ptr->AddNODE(obj1);

To avoid such wrong allocation, a linked list implementation usually does the allocation (e.g. by not passing an existing object to the add function but the data and let the implementation do the allocation):

C++

void DoublyLinkedList::AddNODE(const Persons& person)
{
    // Requires a constructor that accepts a Persons reference
    NODE *newNode = new NODE(person);
    // ...
}

There is also no need to use heap allocation for the box member (which is never getting deleted in your implementation). Just use the structure as member.

Instead of finding the reason of your crash I suggest to rethink your design. There are plenty of examples.

Con Cop Con13-Sep-17 19:22

Con Cop Con

13-Sep-17 19:22

Hi,
I have problem this,

I use VPN China, dont access Google, face,... I create proxy server by C++ (HP Socket) then access to , however it only run when local ip, public don't active. Can you help me consult to fix it.

Thank you

Re: Solution access internet by proxy server c++

jschell18-Sep-17 12:32

jschell

18-Sep-17 12:32

Lot of unknowns in that very general question.

A VPN would normally look like the following

Client -> (request) -> VPN -> ('internet')

I proxy might look like the following (but other configs possible.)

Client -> (request) -> Proxy -> VPN -> ('internet')

A 'local' ip address would generally mean something that would not go to the internet at all since it would normally be private. Or at least routed internally. Internet networks will reject a private IP address. But even if that it not what you mean it would suggest that your VPN is still not in play.

If you are not sure you can google the following

IP public private

Also not sure what you wrote (proxy or VPN) but you might validate where that service is actually calling via debugging. One possibility there, depending on what you actually have, is that your proxy is not using the VPN at all.

Linker error

Vaclav_12-Sep-17 15:53

12-Sep-17 15:53

I am compiling C code for embedded application using TCF.
My "debug" compile is on x86 and works fine
My "release" on ARM (raspberry Pi ) compiles but won't link on ARM platform with identical compiler "Settings" options.

GCC on x86 - command “gcc”

with #include
#include "/usr/local/include/wiringPiSPI.h"

It compiles and link and run the code on x86 platform.

-I"-I/usr/local/include -L/usr/local/lib -lwiringPi" -O0 -g3 -Wall -c -fmessage-length=020:23:17 ****

Results of build

Incremental Build of configuration Debug for project ESA_SPI ****
make all
Building file: ../src/ESA_SPI.c
Invoking: Cross GCC Compiler
gcc -I"-I/usr/local/include -L/usr/local/lib -lwiringPi" -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/ESA_SPI.d" -MT"src/ESA_SPI.o" -o "src/ESA_SPI.o" "../src/ESA_SPI.c"
Finished building: ../src/ESA_SPI.c

Building target: ESA_SPI
Invoking: Cross GCC Linker
gcc -o "ESA_SPI" ./src/ESA_SPI.o -lwiringPi -lrt -lpthread -lm -lcrypt
Finished building target: ESA_SPI

20:23:18 Build Finished (took 288ms)

<b>Here are the options and compiler / linker outputs on ARM platform.</b>

GCC on ARM with command arm-linux-gnueabihf-gcc

-I"-I/usr/local/include -L/usr/local/lib -lwiringPi" -O3 -Wall -c -fmessage-length=0

20:29:57 Build Finished (took 127ms)

20:29:57 **** Incremental Build of configuration Release for project ESA_SPI ****
make all
Building file: ../src/ESA_SPI.c
Invoking: Cross GCC Compiler
arm-linux-gnueabihf-gcc -I"-I/usr/local/include -L/usr/local/lib -lwiringPi" -O3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/ESA_SPI.d" -MT"src/ESA_SPI.o" -o "src/ESA_SPI.o" "../src/ESA_SPI.c"
Finished building: ../src/ESA_SPI.c

Building target: ESA_SPI
Invoking: Cross GCC Linker
arm-linux-gnueabihf-gcc -o "ESA_SPI" ./src/ESA_SPI.o -lwiringPi -lrt -lpthead -lm -lcrypt
/usr/lib/../lib/libwiringPi.so: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
make: *** [ESA_SPI] Error 1

20:29:57 Build Finished (took 280ms)

My question is - where does the "<b>lib</b>wiringPi.so" error come from?

What needs to be optioned differently for the ARM compiler or do I have to modify something else?

Any help would be appreciated to resolve / give me a hit how to fix this.
Cheers
Vaclav

Richard MacCutchan12-Sep-17 19:12

Richard MacCutchan

12-Sep-17 19:12

It looks like the lib/wiringPi.so file is not in ARM format. You need to rebuild it.

CPallini13-Sep-17 1:25

CPallini

13-Sep-17 1:25

As Richard stated, the library must be cross-compiled for ARM is order to be correctly linked to your application (please note, the build instructions on WiringPi website[^] assume you are building it on the actual raspberry PI.).

Vaclav_13-Sep-17 3:14

13-Sep-17 3:14

Yes, I did follow this instruction on both x86 and ARM

To build/install there is a new simplified script:

$ cd ~/wiringPi
$ ./build

The new build script will compile and install it all for you – it does use the sudo command at one point, so you may wish to inspect the script before running it.

I just do not get where the "lib" prefix came from.

I am still not too comfortable with Linux files scheme so I may be "linked" to wrong place.

I need to study "make" to get better idea how compiler does "build" and where all those "includes" come from.

For example how does "include /usr/local/include " translates to "/home/pi/wiringPi/wiringPi"?
Or does it ?

Stand by , I'll come back after I take a closer look at compiler and make.

Thanks for your help.
Vaclav

FYI here is what is in directory and apparently the *.h file in question is "included" but I see only "libwiringPi.so.2.44" file.

root@pi:/home/pi/wiringPi/wiringPi# ls
ads1115.c max31855.c mcp23s17.o piHiPri.c sr595.c
ads1115.h max31855.h mcp23x0817.h piHiPri.o sr595.h
ads1115.o max31855.o mcp23x08.h piThread.c sr595.o
bmp180.c max5322.c mcp3002.c piThread.o wiringPi.c
bmp180.h max5322.h mcp3002.h pseudoPins.c wiringPi.h
bmp180.o max5322.o mcp3002.o pseudoPins.h wiringPiI2C.c
COPYING.LESSER mcp23008.c mcp3004.c pseudoPins.o wiringPiI2C.h
drcNet.c mcp23008.h mcp3004.h rht03.c wiringPiI2C.o
drcNet.h mcp23008.o mcp3004.o rht03.h wiringPi.o
drcNet.o mcp23016.c mcp3422.c rht03.o wiringPiSPI.c
drcSerial.c mcp23016.h mcp3422.h sn3218.c wiringPiSPI.h
drcSerial.h mcp23016.o mcp3422.o sn3218.h wiringPiSPI.o
drcSerial.o mcp23016reg.h mcp4802.c sn3218.o wiringSerial.c
ds18b20.c mcp23017.c mcp4802.h softPwm.c wiringSerial.h
ds18b20.h mcp23017.h mcp4802.o softPwm.h wiringSerial.o
ds18b20.o mcp23017.o pcf8574.c softPwm.o wiringShift.c
htu21d.c mcp23s08.c pcf8574.h softServo.c wiringShift.h
htu21d.h mcp23s08.h pcf8574.o softServo.h wiringShift.o
htu21d.o mcp23s08.o pcf8591.c softTone.c wpiExtensions.c
libwiringPi.so.2.44 mcp23s17.c pcf8591.h softTone.h wpiExtensions.h
Makefile mcp23s17.h pcf8591.o softTone.o wpiExtensions.o
root@pi:/home/pi/wiringPi/wiringPi#

leon de boer13-Sep-17 4:02

13-Sep-17 4:02

Using the GNU Compiler Collection (GCC): Link Options[^]

>>>>>> The only difference between using an -l option and specifying a file name is that -l surrounds library with ‘lib’ and ‘.a’ and searches several directories.

In vino veritas

jschell13-Sep-17 8:23

jschell

13-Sep-17 8:23

...that brings back memories (of trying to figure exactly that out.)

Jochen Arndt13-Sep-17 4:14

13-Sep-17 4:14

Your compiler command lines looks a little bit weird regarding the double quotes (especially the first group with the trailing -I):

arm-linux-gnueabihf-gcc -I"-I/usr/local/include -L/usr/local/lib -lwiringPi" -O3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/ESA_SPI.d" -MT"src/ESA_SPI.o" -o "src/ESA_SPI.o" "../src/ESA_SPI.c"

When there are no spaces in the arguments, the quotes can be omitted:

arm-linux-gnueabihf-gcc -I/usr/local/include -O3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/ESA_SPI.d" -MT"src/ESA_SPI.o" -o "src/ESA_SPI.o" "../src/ESA_SPI.c"

Note also that it is not necessary to specify library pathes and libraries when compiling only (option -c). These have to specified when linking (see below).

/usr/lib/../lib/libwiringPi.so: file not recognized: File format not recognized

You are linking with the shared library /usr/lib/libwiringPi.so. As far as I remember, the default WiringPi build will install the library into /usr/local/lib/. Check where the file in /usr/lib comes from and try to build after deleting (or renaming/moving) it. But before doing so fix your linker command line:

arm-linux-gnueabihf-gcc -o "ESA_SPI" ./src/ESA_SPI.o -lwiringPi -lrt -lpthead -lm -lcrypt

That is missing the additional library path and has a wrong pthread name (which does not care because GCC will detect the use of pthreads and link the library automatically so that it can be omitted):

arm-linux-gnueabihf-gcc -L/usr/local/lib -o "ESA_SPI" ./src/ESA_SPI.o -lwiringPi -lrt -lpthread -lm -lcrypt

Regarding the names libwiringPi.so and the linker command line option -lwiringPi:
With Linux, all library files names should begin with lib and have the extension .so (or .a for static libraries). You can optionally (but it is usual) pass the short name (without prefix and extension) to the GCC linker command line.

Vaclav_13-Sep-17 9:05

13-Sep-17 9:05

Thanks for all the replies.
I did some research and I am convinced that the missing library is in different directory.
Makes no sense since the wiringPi was made for ARM / Raspberry PI and that is where the problem is.

I have added verbose option and this is what I get now

3:41:22 **** Build of configuration Release for project ESA_SPI ****
make all
Building file: ../src/ESA_SPI.c
Invoking: Cross GCC Compiler
arm-linux-gnueabihf-gcc -I"-I/usr/local/include -L/usr/local/lib -lwiringPi" -O3 -v -Wall -c -fmessage-length=0 -MMD -MP -MF"src/ESA_SPI.d" -MT"src/ESA_SPI.o" -o "src/ESA_SPI.o" "../src/ESA_SPI.c"
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabihf-gcc
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.8.4-2ubuntu1~14.04.1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabihf/include/c++/4.8.4 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-armhf-cross/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-armhf-cross --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-armhf-cross --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libgcj --enable-objc-gc --enable-multiarch --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-linux-gnueabihf --program-prefix=arm-linux-gnueabihf- --includedir=/usr/arm-linux-gnueabihf/include
Thread model: posix
gcc version 4.8.4 (Ubuntu/Linaro 4.8.4-2ubuntu1~14.04.1)
COLLECT_GCC_OPTIONS='-I' '-I/usr/local/include -L/usr/local/lib -lwiringPi' '-O3' '-v' '-Wall' '-c' '-fmessage-length=0' '-MMD' '-MP' '-MF' 'src/ESA_SPI.d' '-MT' 'src/ESA_SPI.o' '-o' 'src/ESA_SPI.o' '-march=armv7-a' '-mfloat-abi=hard' '-mfpu=vfpv3-d16' '-mthumb' '-mtls-dialect=gnu'
/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/cc1 -quiet -v -I -I/usr/local/include -L/usr/local/lib -lwiringPi -imultiarch arm-linux-gnueabihf -MMD src/ESA_SPI.d -MF src/ESA_SPI.d -MP -MT src/ESA_SPI.o ../src/ESA_SPI.c -quiet -dumpbase ESA_SPI.c -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb -mtls-dialect=gnu -auxbase-strip src/ESA_SPI.o -O3 -Wall -version -fmessage-length=0 -fstack-protector -Wformat-security -o /tmp/ccya3GZh.s
GNU C (Ubuntu/Linaro 4.8.4-2ubuntu1~14.04.1) version 4.8.4 (arm-linux-gnueabihf)
compiled by GNU C version 4.8.4, GMP version 5.1.3, MPFR version 3.1.2-p3, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/arm-linux-gnueabihf"
ignoring nonexistent directory "/usr/include/arm-linux-gnueabihf"
ignoring nonexistent directory "-I/usr/local/include -L/usr/local/lib -lwiringPi"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/include
/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/include-fixed
/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/include
/usr/include
End of search list.
GNU C (Ubuntu/Linaro 4.8.4-2ubuntu1~14.04.1) version 4.8.4 (arm-linux-gnueabihf)
compiled by GNU C version 4.8.4, GMP version 5.1.3, MPFR version 3.1.2-p3, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: a580284b5d73d9bdb7f04a1c16c98639
COLLECT_GCC_OPTIONS='-I' '-I/usr/local/include -L/usr/local/lib -lwiringPi' '-O3' '-v' '-Wall' '-c' '-fmessage-length=0' '-MMD' '-MP' '-MF' 'src/ESA_SPI.d' '-MT' 'src/ESA_SPI.o' '-o' 'src/ESA_SPI.o' '-march=armv7-a' '-mfloat-abi=hard' '-mfpu=vfpv3-d16' '-mthumb' '-mtls-dialect=gnu'
/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/bin/as -v -I -I/usr/local/include -L/usr/local/lib -lwiringPi -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -meabi=5 -o src/ESA_SPI.o /tmp/ccya3GZh.s
GNU assembler version 2.24 (arm-linux-gnueabihf) using BFD version (GNU Binutils for Ubuntu) 2.24
COMPILER_PATH=/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/:/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/:/usr/lib/gcc-cross/arm-linux-gnueabihf/:/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/:/usr/lib/gcc-cross/arm-linux-gnueabihf/:/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/bin/
LIBRARY_PATH=/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/:/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/lib/../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/lib/:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-I' '-I/usr/local/include -L/usr/local/lib -lwiringPi' '-O3' '-v' '-Wall' '-c' '-fmessage-length=0' '-MMD' '-MP' '-MF' 'src/ESA_SPI.d' '-MT' 'src/ESA_SPI.o' '-o' 'src/ESA_SPI.o' '-march=armv7-a' '-mfloat-abi=hard' '-mfpu=vfpv3-d16' '-mthumb' '-mtls-dialect=gnu'
Finished building: ../src/ESA_SPI.c

Building target: ESA_SPI
Invoking: Cross GCC Linker
arm-linux-gnueabihf-gcc -o "ESA_SPI" ./src/ESA_SPI.o -libwiringPi.so.2.44
/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/bin/ld: cannot find -libwiringPi.so.2.44
collect2: error: ld returned 1 exit status
make: *** [ESA_SPI] Error 1

13:41:23 Build Finished (took 267ms)

So the "error is" that I am using crosscompiler and
the "make" is looking for plain gcc thus this

ignoring nonexistent directory "/usr/local/include/arm-linux-gnueabihf"

is telling the real story.

But the compiler is just ignoring non existed directory and linker is looking in wrong /non specified directory.

If you fellows just confirm my finding as OK I'll will muddle thru it and fix it.

Still confused why I have to enter "ibwiringPi2.44" to end up with "libwiringPi2.44"

I wonder if the "suffix / version " is also causing issue and plain "wiringPi" won't do.

Thanks for all the support.
Vaclav

PS I'll eventually fix all the weird stuff, after I get the linker libraries working on ARM.

Jochen Arndt14-Sep-17 3:38

14-Sep-17 3:38

You have build wiringPi on the Pi using the build script. That will install the libraries to /usr/local/lib. Just have a look what is getting installed:

joe@raspi-cross:~/raspi/sysroot/usr/local/lib$ ls -l libw*
lrwxrwxrwx 1 joe joe    22 Jan 20  2016 libwiringPiDev.so -> libwiringPiDev.so.2.31
-rwxr-xr-x 1 joe joe 23232 Jan 20  2016 libwiringPiDev.so.2.31
lrwxrwxrwx 1 joe joe    19 Jan 20  2016 libwiringPi.so -> libwiringPi.so.2.31
-rwxr-xr-x 1 joe joe 55808 Jan 20  2016 libwiringPi.so.2.31

There are two shared libraries with the version as part of the name and two links that point to those. That is common with Linux. You can have different versions of a library which can be accessed using the full name and links pointing to a specific version (usually the most recent or the only version). This link name can be used instead (and then be shortened to be passed to the linker). So you can use in your case either -llibwiringPi.so.244 or -lwiringPi.

Once installed, you can build your program on the Pi and link it with the library.

But when using cross compilation, you have to make the libraries build on the Pi available to the cross setup. That can be done by copying the files or mounting the Pi file system (or parts of it) on the cross build system. The mounting can be done live (using network shares like NFS), using an image (e.g. by removing the SD card from the Pi and mounting it on the cross system), or some sync mechanism (which requires again network shares during synchronisation). In all cases you have to setup your cross system properly to use the mounted / copied files instead those of the host system itself (and use the cross tools instead of those from the host system).

You may also build wiringPi on the cross system. But then you have to use the cross tools and specify the install directory to be the mounted Pi system instead of the host system. But the Pi system has to be mounted anyway to link with all the ARM libraries instead of the x86 libraries of the host system.

As you can see from the above listing, I have mounted my Pi system at /home/joe/raspi/sysroot so that the cross build tools have access to all Pi files.

I don't know how you have setup your cross compilation system. But you must set the include and library paths to those on the mounted Pi root system using environment variables, specify them in the make scripts, or pass them on the GCC command line.

leon de boer15-Sep-17 22:21

15-Sep-17 22:21

If that is for a Pi2 the compiler settings I find really strange usually it is
-mfpu=neon -mfloat-abi=hard -march=armv7ve -mtune=cortex-a7

Must be a funky linux thing which I avoid like the plague, I only baremetal the Pi.
You see by my baremetal samples I always run those settings as they are optimal
LdB-ECM: Raspberry Pi samples[^]

In vino veritas

modified 16-Sep-17 4:40am.

Vaclav_16-Sep-17 3:02

16-Sep-17 3:02

It is for Pi 3B.
I am currently looking into autotools.
I got the x86 system to compile, link and actually run.
You made a good point these "system designators " are a mess.
The autotool uses three of them and naturally can identify the one where the Eclipse resides - on x86.
And they call it "build" (platform) , than the "host" is where the ARM - Raspberry is.
Exactly opposite of Eclipse terminology!

This terminology just does not jive with plain "debug" and "release" I am accustomed in C / C++.

It actually looks as both "build" and "host" are compiled / linked same time.
Using -v verbose option whenever I can!

The intergeneration of autotools into Eclipse stinks.
Too many "make" files with no way to easy see how they interact.

Cheers
Vaclav

leon de boer16-Sep-17 3:16

Clarification of Debug/Release mode

16-Sep-17 3:16

Correct settings for a Pi3 are
-mfpu=neon-vfpv4 -mfloat-abi=hard -march=armv8-a -mtune=cortex-a53

But I am questioning if you might have to match the compiler settings for the O/S which may even be for an ARM6 given the O/S distribution probably runs on a Pi1.

In vino veritas

modified 16-Sep-17 11:03am.

ForNow11-Sep-17 2:24

ForNow

11-Sep-17 2:24

Just looking for a clarification on Release/debug mode

Isn't it true that I can generate Symbols .pdb file for a release Mode with the /Zi option

so In debug it's Just using code generated by the pre-processor _DEBUG option

such as #ifdef _DEBUG #define new debug_new #endif

where a different heap storage allocator is used among other things

Thanks

Jochen Arndt11-Sep-17 3:21

11-Sep-17 3:21

The compiler and linker options are set initially to default values for the selected mode (debug or release).

You can change the options according to your needs. Some tips:

Use a new setting (e.g. by copying a default setting) if not changing basic options like the warning level
You are not allowed to ship an application that is statically linked with debug versions of the run-time libraries or ship the dynamic debug versions with your applications.

The NDEBUG symbol is a standard C symbol that controls if the assert functions are active or not. You can remove it temporarily in release builds to test your code.

The _DEBUG symbol is a MS specific extension. It is set according to the selected /M linker option and controls if the release or debug versions of the run-time libraries should be used.

Finally, the remaining main differences are that debug builds are compiled without optimisations and with (optional) additional checks like initialising memory and using guard bytes to detect out-of-bound accesses.

leon de boer11-Sep-17 15:51

11-Sep-17 15:51

Commercially I don't ever use the DLL versions of the runtime libraries we live with the blowup in EXE code size.

So for MFC I have the setting "Use Standard Windows Libraries"
For C/C++ code generation I use "Multi-threaded (/MT)" in release mode and "Multi-threaded Debug (/MTd)" for debug

The reason for it is sometime down the track your runtime DLL will fall foul of a new windows version. The compiler groups behind the runtime library are not as forward thinking as the proper O/S programmers at Microsoft. In general if you are using just the windows API the O/S programmers will patch those calls to still operate for old code although there is usually a speed penalty.

I have code written originally for Windows 98 that still works on Windows 10, but I have had code written for runtime libraries that could survive between minor version changes of Windows.

The school of hard knocks has taught me to avoid the runtime libraries at all cost because they are a liability.

In vino veritas

ForNow11-Sep-17 15:58

ForNow

11-Sep-17 15:58

Leon when you say run time you referring to i.e. itoa, sprintf, strtol ? I guess for those you can write your own code

leon de boer12-Sep-17 8:33

12-Sep-17 8:33

No the VC and MFC runtime libraries. Pull up control panel and go to the installed apps and features and roll to to Microsoft Visual C++. You will have a pile of things labelled as Visual Studio VC++ xxxx redistributable. Those are the same junk you have to package up with you EXE file when you go to place it on a new machine. All they are doing is trying to reduce the footprint of the EXE file itself by sitting it on a runtime library. It's the same as what Visual Basic does with it's runtime libraries and if I wanted to use Visual Basic I would write in Visual Basic not C++. Those redistributable libraries quite often develop bugs with new versions of Windows you notice you have to install them for every windows version you have a program written for. On my machine I have so many versions ... 2005, 2 x 2008, 2010, 2 x 2012, 2013, 2015, 2017

Using the settings I gave you the you create statically linked executable it flattens the EXE to only use the physical standard windows API in static linking. It means the EXE does not need anything else you can install it on a new Windows machine that has never seen a VC++ xxxx redistributable. The cost is it can be slower to compile because what looks like a minor change may setup big changes to what it does on code to the windows API and the EXE size will be some percentage bigger. As a guide my largest CAD program I make which is close to a million lines makes an EXE just over 3MBytes so it really isn't that dramatic.

There used to be a problem with console apps where they would call out to the library but even that changed since Windows 7. The trick is you don't actually build a console app, you build a windows app and then call AllocConsole. The thing you end up with on screen looks and behaves like a console APP, but underneath they are very different. You will note the only attachment of the virtual console is kernel32.dll via kernel32.lib Smile | :)

AllocConsole function - Windows Console | Microsoft Docs[^]
To make life interesting on Windows 10 they also allow users to bring up the old legacy console with an executable.
Windows 10 Command Prompt: New Console vs. Legacy Console[^]
One of the jobs I always do on Windows 10 is throw a program error if some fiddler sets that thing as it makes things unstable.

There are two caveats
- All libraries the executable is linked to have to be compiled with the same setting. So if you are using 3rd party libraries you need to rebuild those entire libraries as well.
- Compiling shared libraries (DLL) with this static linking will sometimes throw up multiple definitions. It used to be a pain it isn't anymore because they introduced an number of linker and section controls which make it rather trivial now.

In vino veritas

modified 12-Sep-17 14:45pm.

ForNow12-Sep-17 8:46

ForNow

12-Sep-17 8:46

Leon

thanks I understand what you are saying I just wanted to know what functions make up the run time libraries

as far as MFC is concerned is it any way connected to the SDK version you are running

Seems like sdk's have .lib file does MFC use that to resolve a call

leon de boer13-Sep-17 18:25