|
Vaclav_Sal wrote: /home/vaclav/TEMPLATE_Cross_GCC_RPI: 1: /home/vaclav/TEMPLATE_Cross_GCC_RPI: Syntax error: "(" unexpected
I get it when I specify
"/home/vaclav/TEMPLATE_Cross_GCC_RPI"
My guess is that you are guessing. You are making one or more assumptions that are incorrect. Some examples.
1. The path that you think you are using (in dialog) is not the one that you are actually putting there.
2. Your code is doing something with the path, from the dialog, and it is that path, not the one in the dialog, that has the problem.
Solution.
1. Find the EXACT line where the error occurs.
2. BEFORE that line log/print the EXACT path that is being used. PUT delimiters around the value so you know exactly where it starts. Such as (pseudo) print '{' + val + '}'.
Take care with 2 that you do not make assumptions. For example if you pass to parameters to the failing line the log/print both of them, do not concatenate.
|
|
|
|
|
jschell wrote: My guess is that you are guessing. My guess is that you are exactly right. 
|
|
|
|
|
No more stupid , what else can I call it?, replies please.
If you read the OP it is the VALID ENTRY to the options text box.
Nothing to do with my code.
If I knew WHERE TCF implements these options I would resolve this myself.Perhaps in my spare time I'll search git for it.
I fail to see how I can describe the problem any differently.
Let's just drop it.
I am using different "Configuration", not TCF, to access the target and it works using SAME, EXACT option TEXT to specify the "remote" file path.
Problem solved (?)
Thanks
|
|
|
|
|
Vaclav_Sal wrote: If I knew WHERE TCF implements these options And if you had mentioned TCF (whatever that is) in the first place you would most likely not have got what you call "stupid replies". Like so many questioners here, you provide only half the information and then blame us when you don't get the correct answer in return.
|
|
|
|
|
As guess, from googling, "TCF" is an open source library that one can use. Because it is open source it can be modified.
Otherwise, for this and other third party libraries, first and best source are the support forums for the library. Might also look through the bug reports for the library since it might be something that is already known.
|
|
|
|
|
Call me dense - but I see this as OS error / verification error and I did my best to find what parameters are expected in the control. At one point Eclipse did confirm the "file" selected.
Unfortunately this TCF is pretty much dead as far as any support from the original vendor.
Please consider this matter closed.
|
|
|
|
|
Hi,
I am developing a service which will install on system level (not on user level). I need the name of current user logged in.
Please suggest to get it.
|
|
|
|
|
|
As a long time user of this forum I must first apologize for OT post.
I am getting desperate to be able to use TCF in Eclipse IDE.
I have been unable to find out HOW to use "TCF Configuration" dialog. I have been posting on Eclipse forums and getting nowhere. This plug in apparently is obsolete / unsupported by anybody technology. There are "power point" tutorials which do not address the actual usage / configuration of the tool.
I am simply looking for somebody who "been there / done that". I do not need code help.
Thanks
|
|
|
|
|
|
Thanks, but...
This is ONE of many I have been tru.
It does not even attempt to explain HOW to configure TCF in most general terms.
Similar tutorial are very high level overviews of a technology which seems to be the answer to programming embedded systems similar to ICE.
I am currentlylooking into another IDE and hope it has better support for TCF than Eclipse.
|
|
|
|
|
Quote: Where can I ask questions about TCF?
Write an E-Mail to the tcf-dev@eclipse.org mailing list.
|
|
|
|
|
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.
|
|
|
|