|
Leon,
I got sidetracked by another issue, and this one was "FIXED" - see my next post.
From my research - it is optioned / initialized in the library I have build and I really do not understand what it supposedly doing with just the options being set. It is definitely incomplete.
I did try to delete the options, but it is "built-in".
|
|
|
|
|
SOLVED
Added --coverage to main program linker options.
From description it should make no difference if it is
complier or linker option.
Still not sure if I ever use if it supposedly created (where?) the "gconv" utility "executable" which I did not program.
|
|
|
|
|
Using the code below (called from void CLoadPngDlg::OnPaint()) I am trying to view a PNG file that already included in the resource (IDB_FULLSCRINFOBAR_OPAQ_TEST).
As you can see in the image attached the bottom red line and the rightmost column of pixels are not shown.
https://i.imgur.com/Ug6gYjr.jpg
Image Attached[^]
What seems to be the problem here?
BOOL CLoadPngDlg::ShowPngAt(CDC *dcWnd) {
CGdiPlusBitmapResource *pPngChannel;
UINT nWidth,nHeight;
CRect rectClient;
CBitmap Bitmap, *pOldBitmap;
CDC bitmapDC;
CDC *dialogDC;
pPngChannel = NULL;
pPngChannel = new CGdiPlusBitmapResource;
if (!pPngChannel->Load(IDB_FULLSCRINFOBAR_OPAQ_TEST, _T("PNG"))) {
delete pPngChannel;
return TRUE;
}
GetWindowRect(&rectClient);
nWidth = pPngChannel->m_pBitmap->GetWidth();
nHeight = pPngChannel->m_pBitmap->GetHeight();
bitmapDC.CreateCompatibleDC( dcWnd );
Bitmap.CreateCompatibleBitmap(dcWnd, nWidth, nHeight);
pOldBitmap = bitmapDC.SelectObject(&Bitmap);
Gdiplus::Graphics graphics(bitmapDC.GetSafeHdc());
graphics.DrawImage(*pPngChannel, 0, 0);
dcWnd->BitBlt(0, 0, rectClient.Width(), rectClient.Height(), &bitmapDC, 0, 0, SRCCOPY );
bitmapDC.SelectObject( pOldBitmap );
bitmapDC.DeleteDC();
if (pPngChannel != NULL)
delete pPngChannel;
return FALSE;
}
sdancer75
|
|
|
|
|
Where is the code for CGdiPlusBitmapResource? I can only assume that it returns the wrong values for height and width.
|
|
|
|
|
Thanks for your answer. The CGdiPlusBitmapResource is part of an older codeproject.com article at
Loading JPG & PNG resources using GDI+[^]
Anyway, I found the root of the problem. I had to call DrawImage with the size of the image. Now all works just fine.
graphics.DrawImage(*pPngChannel, 0, 0, 800, 50);
sdancer75
|
|
|
|
|
THIS IS embarrassing
SOMEHOW MY MAIN PROJECT BECAME PLAIN gcc
I NEED TO REVERt BACK TO CROSSCOMPiled GCC!
Build the library for ARM, easy task in Eclipse ( for a change).
Still no go. missing some option.
Never mind it is simple
the library is compiled on x86 ,
now I need it to compile it for ARM.
Any opposing opinions are welcome.
I wish I could do it on x86.
Any file .a ,or .so perfectly working , and linked using -l / -L , in GCC compiled application CANNOT be accessed in crosscompiled version of the SAME project.
See attached highlighted part of the " make " output text.
Building target: RPI_BT_CLIENT
Invoking: Cross G++ Linker
arm-linux-gnueabihf-g++ -L"/media/z/DEV_COPY_LABEL/ECLIPSE_FOLDER/2019-12/Eclipse_2019_12/eclipse/Workspace_2019_12/RPI_BT_LIB/Debug" -L/media/z/MISC_COPY_LABEL/RPI_library/lib -L"/media/z/DEV_COPY_LABEL/ECLIPSE_FOLDER/2019-12/Eclipse_2019_12/eclipse/Workspace_2019_12/LIB_SHARED/Debug" -
....
bluetooth_sample_SDP.o -lbluetooth -lLIB_SHARED
.....
/media/z/DEV_COPY_LABEL/ECLIPSE_FOLDER/2019-12/Eclipse_2019_12/eclipse/Workspace_2019_12/LIB_SHARED/Debug/libLIB_SHARED.so: file not recognized: File format not recognized
Does crosscompiler expect some other option ??
Please no more "how to use -l / -L"
modified 29-Jan-20 13:13pm.
|
|
|
|
|
You're probably trying to link in an x86-64 version of the lib, not ARM.
|
|
|
|
|
and you are probably correct.
I am getting this error
lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-linux-gnu/5/crtend.o /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crtn.o
/usr/bin/ld: skipping incompatible /media/z/DEV_COPY_LABEL/ECLIPSE_FOLDER/2019-12/Eclipse_2019_12/eclipse/Workspace_2019_12/RPI_BT_LIB_ARM/Debug/libRPI_BT_LIB_ARM.a when searching for -lRPI_BT_LIB_ARM
/usr/bin/ld: cannot find -lRPI_BT_LIB_ARM
The error is little confusing - skipping and cannot find it - both ?
And indeed my X86 is 64 bits and the RPI is 32.
But it only bothers the additional library.
I'll add -m32 and watch for smoke
|
|
|
|
|
Bummer
-m32 does not compute as ARM option
|
|
|
|
|
Vaclav_ wrote: The error is little confusing - skipping and cannot find it - both ?
Not really. The linker found a copy of the lib, but it has the wrong architechture, so it skipped over that one, but then did not find a suitable candidate. If you had x86, x86-64, PowerPC and MIPS versions of that lib, I expect you would get skipped messages for each.
I notice you're calling /usr/bin/ld. If you are cross compiling for an rpi, should that be calling /usr/bin/arm-linux-guneeabihf-ld? I think maybe you've misconfigured your project to produce X86 output, and not ARM.
|
|
|
|
|
I am sorry.
Yes, I got it all mixed up as far as architecture. .
From the start of this project I did not like terms "server / client".
Now I got caught in my own trap.
I am renaming my projects
RPI_BT_SERVER_X86 - runs on PC X86-64
RPI_BT_CLIENT_ARM runs on ARM7 32 bits
Cheers
|
|
|
|
|
The task is to replace - looks for all occurrences of string from and replaces it with string to.
It is possible to specify one or more files on which to perform the replace
operation(s) in a single replace command.
and this is my code:
void replace(char* OldWord, char* NewWord)
{
char *result = NULL;
char buff[1000];
char c;
char line[1000];
FILE * f = fopen ("file1.txt", "r+");
int count=0;
while (fgets(buff, sizeof(buff), f))
{
result = replaceWord(buff, OldWord, NewWord);
//
}
//
//free(result);
}
char *replaceWord(const char *s, const char *oldW,const char *newW)
{
char *result;
int i, cnt = 0;
int newWlen = strlen(newW);
int oldWlen = strlen(oldW);
static int k=0;
k++;
char newline[1000];
FILE * fp;
// printf("%s\n",oldW);
//printf("%s\n",newW);
// Counting the number of times old word
// occur in the string
for (i = 0; s[i] != '\0'; i++)
{
if (strstr(&s[i], oldW) == &s[i])
{
cnt++;
// Jumping to index after the old word.
i += oldWlen - 1;
}
}
// Making new string of enough length
result = (char *)malloc(i + cnt * (newWlen - oldWlen) + 1);
i = 0;
while (*s)
{
// compare the substring with the result
if (strstr(s, oldW) == s)
{
strcpy(&result[i], newW);
i += newWlen;
s += oldWlen;
fp = fopen ("file1.txt", "w");
rewind(fp);
fseek(fp,i-newWlen,SEEK_SET);
fprintf(fp,"%s\n",result);
}
else
{
result[i++] = *s++;
}
}
result[i] = '\0';
fp = fopen ("file1.txt", "w");
fprintf(fp,"%s\n",result);
// printf("%d\n",k);
return result;
}
the replace function does not give the desired output
The command line looks like:
./a.out replace old_word new_word files.txt
must replace old_word with the new_word in all files.
|
|
|
|
|
Member 12957547 wrote: It is possible to specify one or more files on which to perform the replace
operation(s) in a single replace command.
Why "in a single replace command"?
Why not just open your files in the loop and perform the replacement in each file? 
|
|
|
|
|
because I do not know how many items get from the CLI
|
|
|
|
|
Member 12957547 wrote: because I do not know how many items get from the CLI |
Yes, you do, or at least main() does.
int main(int argc, char **argv)
argc is the number of arguments passed to main, and argv is an array of strings containing the command line arguments. Remeber that argv[0] is the program name, so argc is always > 0.
The following will print all the command line arguments
#include <stdio>
int main(int argc, char **argv)
{
for(int i = 0; i < argc; ++i)
printf("argv[%d] = \"%s\"\n", i, argv[i];
return0;
}
|
|
|
|
|
Haven't tried to run your code, but I do notice a couple things:
1: you call fopen() several times, but there's no corresponding fclose(). If you had a large file (say the text of the bible), and wanted to replace, "god" with "jimmy", you would probably run out of file handles before completing the task.
2: you continually call fopen on the same file. fopen("file1.txt", "w") truncates the file, so some future read may return EOF unexpectedly. [NB not necessarily the next read, as the call to fgets might fill an input buffer, which following calls use, rather than continually reading from the file] My suggestion would be to open a temporary file and write your output there, then copy or replace the input file with the temp file. tmpfile() might be useful, here.
3: fgets() reads up to size-1 bytes from the input stream. What happens if you have very long lines (over 999 chars, in your case), and the word you want occupies chars 996-1003? You'll get the first 3 chars in one read and the remaining 4 in the next, missing an occurrence. Might I suggest you look at getline().
4: do you need to concern yourself with word case? Do you need to replace "babble" with "brook", "Babble" with "Brook" and "BABBLE" with "BROOK"?
|
|
|
|
|
Member 12957547 wrote:
the replace function does not give the desired output
If that is the case, I'd take a step back and get it working before worrying about files. Just send the function a string of characters, and the find/replace terms. After that, then rope the file contents back in.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
A couple of things I've noticed:
1. You are always using 'file1.txt' in your code, not the filename(s) passed as argument
2. As has been pointed out, lines can be longer than 1000 chars.
3. You never close the file you've opened. That will cause changes in one file buffer to overwrite previous changes once the files are closed (or at the end of the program).
4. You only check for one occurence of a word per line. What if there are multiple occurrences?
Suggestions:
- As already pointed out, start with your replace functions and make sure they work as intended, before dealing with files!
- Make sure you always close the files you've opened
- Write the modified text into another, temporary file. Later erase the original file, and rename the temporary one. That way you can just keep on reading/writing without needing to close/open the file over and over again.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Hope it is OK to make new post.
I am still working on this assumption:
other
An object file to be fed straight into linking. Any file name with no recognized suffix is treated this way.
Adding full path to desired library to be added to existing library resolved the
"cannot find " issue.
Now the gcc++ needs to be told to actually link, contrary to the "other" instruction taken from Linux documentation.
I get same error when using libbluetooth.a.
'MODULE/M_TEST/CTEST.o' '-o' 'MODULE/M_TEST/CTEST.o' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
Finished building: ../MODULE/M_TEST/CTEST.cpp
g++: warning: /usr/lib/x86_64-linux-gnu/bluetooth: linker input file unused because linking not done
Building file: ../MODULE/M_SOCKET/CSOCKETCOMMON.cpp
Invoking: GCC C++ Compiler
|
|
|
|
|
You need to show us the command you are using to do the build. The message above suggests that you are only invoking the compile of some source module(s), so no library is needed.
|
|
|
|
|
Some very odd things here:
Vaclav_ wrote: 'MODULE/M_TEST/CTEST.o' '-o' 'MODULE/M_TEST/CTEST.o' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
That looks wrong. That looks like your compiler command could be boiled down to
g++ CTEST.o -o CTEST.o You're passing in and producing the same .o file, not creating an executable, only an intermediate object. In which case the g++ warning makes sense, since its telling you that the lib wasn't used to create the .o file. In which case you should be getting a g++ fatal error input file is same as output file.
Second thing is the warning itself. The path given is /usr/lib/x86_64-linux-gnu/bluetooth. Normally that would be libbluetooth.a. In which case the linker should be able to pick it up as -lbluetooth, since its in the expected location. It just doesn't have a name format that the linker recognizes as a library. I'd say say something messed up when installing the library, if this is indeed the case and you've not just messed up copying the output from your system to the forum.
|
|
|
|
|
As already noted by k5054, you (-o option) are asking the g++ to NOT perform the linking step.
Nevermind.
(thanks to k5054)
modified 28-Jan-20 15:54pm.
|
|
|
|
|
Oops, Ha Ha, actually, we both got that wrong. The compiler is quite happy to link an executable into a file named foo.o e.g.
$ g++ hello.cpp -o hello.o
$ ./hello.o
Hello World!
$
Its the -c option that compiles but does not link, so that must have been included in the command sent to the compiler.
|
|
|
|
|
Yes, of course you are right. Thank you for pointing out.
|
|
|
|
|
Stand-by.
I build some more test apps and "discovered" that type .so library has STANDARD IDE options for linker , but type .a , which I have been messing with, does NOT.
Also neither one of them show -l option, only -L.
Basically - forget IDE, back to GCC raw options.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
