|
In the following code, I've implemented a doubly linked list in which each node is a structure with the following fields:
firstName, secondName, CNP, Email;
When I call the function ptr->DeleteNODE for the fifth time to delete the last node left in the list the code crashes.
Deleting nodes is done from the beginning of the list.
I don't understand why it's crashes.
#include <iostream>
#include <cstring>
using namespace std;
struct Persons
{
string firstName;
string secondName;
string CNP;
string Email;
};
class NODE
{
private:
NODE *next;
NODE *previous;
public:
Persons *box = new Persons();
NODE(string firstName, string secondName, string CNP, string Email)
{
box->firstName = firstName;
box->secondName = secondName;
box->CNP = CNP;
box->Email = Email;
}
void SetNext(NODE *next)
{
this->next = next;
}
NODE* GetNext()
{
return next;
}
void SetPrevious(NODE *previous)
{
this->previous = previous;
}
NODE *GetPrevious()
{
return previous;
}
};
class DoublyLinkedList
{
private:
NODE *head;
public:
DoublyLinkedList()
{
head = NULL;
}
bool isEmpty()
{
return head == NULL;
}
void AddNODE(NODE *newNode)
{
if (isEmpty())
{
newNode->SetPrevious(NULL);
head = newNode;
}
else
{
NODE *temp = head;
while (temp->GetNext() != NULL)
temp = temp->GetNext();
temp->SetNext(newNode);
newNode->SetPrevious(temp);
}
newNode->SetNext(NULL);
}
void DeleteNODE()
{
if (isEmpty())
cout << "\n List is Empty." << endl;
NODE *temp = head;
if (head->GetNext() != NULL)
{
head = head->GetNext();
head->SetPrevious(NULL);
}
else
head = NULL;
delete temp;
}
void Print()
{
NODE *temp = head;
while (temp != NULL)
{
cout << "\n First Name : " << temp->box->firstName;
cout << "\n Second Name : " << temp->box->secondName;
cout << "\n CNP : " << temp->box->CNP;
cout << "\n Email : " << temp->box->Email;
temp = temp->GetNext();
cout << endl;
}
}
};
int main()
{
DoublyLinkedList *ptr = new DoublyLinkedList();
NODE obj1("Dragu", "Stelian", "1911226284570", "dragu_stelian@yahoo.com");
NODE obj2("Dragu", "Mircea", "1891226284462", "mircead.personal@yahoo.com");
NODE obj3("David", "Adrian", "1971226284462", "david_adrian@yahoo.com");
NODE obj4("Afrem", "Dragos", "1981246627446", "afrem_dragos@yahoo.com");
NODE obj5("Sandu", "Marius", "1984225774462", "sandu.marius@yahoo.com");
ptr->AddNODE(&obj1);
ptr->AddNODE(&obj2);
ptr->AddNODE(&obj3);
ptr->AddNODE(&obj4);
ptr->AddNODE(&obj5);
ptr->Print();
ptr->DeleteNODE();
ptr->DeleteNODE();
ptr->DeleteNODE();
ptr->DeleteNODE();
ptr->DeleteNODE();
ptr->Print();
return 0;
}
|
|
|
|
|
Use your debugger to find the point where it crashes and why. Also, when you create a node you use the same box* each time. I think you should create a new one in the constructor, or maybe move the persons properties into the node class.
|
|
|
|
|
You aren't cleaning up the pointer chain at all
Get out a piece if paper and draw 5 box and draw arrows as next and prev
Now there are 3 cases
1.) delete the first one and draw what needs to happen (it has a special pointer to it, you called it head .. problem)
2.) delete the middle one and draw what needs to happen to the pointers. (2 pointers to clean up)
3.) delete the last one and draw what needs to happen (which may or may not differ to 2 depends how you set it up)
Paper and planning are you friend in programming.
In vino veritas
|
|
|
|
|
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):
void DoublyLinkedList::AddNODE(const Persons& person)
{
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.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
It looks like the lib/wiringPi.so file is not in ARM format. You need to rebuild it.
|
|
|
|
|
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.).
|
|
|
|
|
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#
|
|
|
|
|
|
...that brings back memories (of trying to figure exactly that out.)
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
Leon when you say run time you referring to i.e. itoa, sprintf, strtol ? I guess for those you can write your own code
|
|
|
|
|
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 
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.
|
|
|
|
|
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
|
|
|
|
|
Again I don't use MFC enough to answer this definitively but I will give you want I expect to happen and these days you have the source code to MFC so you can rebuild it any way you want. So lets start the fishing.
If it works like everything else on VS the header file will redirect it to the lib directory for MFC, for VS 2017 that will be
C:\Program Files\Microsoft Visual Studio 14.0\VC\atlmfc\lib on the 32 bit Windows
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\atlmfc\lib on 64 bit Windows
So I go there and I find lots of lib files which I expected. Now if I go up one directory and down to the include directory (I will assume 32 bit windows)
C:\Program Files\Microsoft Visual Studio 14.0\VC\atlmfc\include
Then pull up the main MFC header file afx.h you will see this, which is how they control which library gets used.
#ifndef _AFXDLL
#ifdef _AFX_NO_MFC_CONTROLS_IN_DIALOGS
#ifdef _DEBUG
#pragma comment(lib, "afxnmcdd.lib")
#else
#pragma comment(lib, "afxnmcd.lib")
#endif
#pragma comment(linker, "/include:__afxNoMFCControlSupportInDialogs")
#pragma comment(linker, "/include:__afxNoMFCControlContainerInDialogs")
#endif
#ifndef _UNICODE
#ifdef _DEBUG
#pragma comment(lib, "nafxcwd.lib")
#else
#pragma comment(lib, "nafxcw.lib")
#endif
#else
#ifdef _DEBUG
#pragma comment(lib, "uafxcwd.lib")
#else
#pragma comment(lib, "uafxcw.lib")
#endif
#endif
#else
#ifndef _UNICODE
#ifdef _DEBUG
#pragma comment(lib, "mfc" _MFC_FILENAME_VER "d.lib")
#pragma comment(lib, "mfcs" _MFC_FILENAME_VER "d.lib")
#else
#pragma comment(lib, "mfc" _MFC_FILENAME_VER ".lib")
#pragma comment(lib, "mfcs" _MFC_FILENAME_VER ".lib")
#endif
#else
#ifdef _DEBUG
#pragma comment(lib, "mfc" _MFC_FILENAME_VER "ud.lib")
#pragma comment(lib, "mfcs" _MFC_FILENAME_VER "ud.lib")
#else
#pragma comment(lib, "mfc" _MFC_FILENAME_VER "u.lib")
#pragma comment(lib, "mfcs" _MFC_FILENAME_VER "u.lib")
#endif
#endif
#endif
#ifdef _DLL
#if defined(_DEBUG)
#pragma comment(lib, "msvcrtd.lib")
#else
#pragma comment(lib, "msvcrt.lib")
#endif
#else
#if defined(_DEBUG)
#pragma comment(lib, "libcmtd.lib")
#else
#pragma comment(lib, "libcmt.lib")
#endif
#endif
Does that answer your question? I am slightly confused about your use of the word SDK, you could mean a number of things.
I just did tried a rebuild on the MFC source and no real problems takes about 30minutes you get lots of this deprecated warning junk .. like these
1>viewhtml.cpp
1>c:\program files\microsoft visual studio\2017\community\vc\tools\msvc\14.10.25017\atlmfc\include\afxhtml.h(573): warning C4838: conversion from 'long' to 'ULONG' requires a narrowing conversion
1>c:\program files\microsoft visual studio\2017\community\vc\tools\msvc\14.10.25017\atlmfc\include\afxhtml.h(564): note: while compiling class template member function 'long CHtmlEditCtrlBase<CHtmlEditView>::QueryStatus(long) const'
1>c:\program files\microsoft visual studio 14.0\vc\atlmfc\src\mfc\viewhtml.cpp(1745): note: see reference to function template instantiation 'long CHtmlEditCtrlBase<CHtmlEditView>::QueryStatus(long) const' being compiled
1>c:\program files\microsoft visual studio\2017\community\vc\tools\msvc\14.10.25017\atlmfc\include\afxhtml.h(1669): note: see reference to class template instantiation 'CHtmlEditCtrlBase<CHtmlEditView>' being compiled
1>viewform.cpp
1>viewedit.cpp
1>viewcore.cpp
So you can build your own MFC .lib but you would need to change the afx.h for it to use a different name. You can also mess around and replace the provided ones with your own .. danger danger
In vino veritas
modified 14-Sep-17 0:48am.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
