Solved piecing together my program I wrote in Linux to FreeBSD to get it to work.

userxbw

userxbw

I got my program to compile, but it seg faults / core dumps. So I am just piecing it together to see what works and what changes I need to make a file at a time. Having created a main that declare my files.cpp and within that it has imlib2.h that when I try to just compile the main with the files header declared within main, I get this.
Code: 
[userx@FreeBSD64ssd project]$ c++ main.cpp
In file included from main.cpp:6:
In file included from ./files.cpp:39:
/usr/local/include/Imlib2.h:26:10: error: 'X11/Xlib.h' file not found with
      <angled> include; use "quotes" instead
#include <X11/Xlib.h>
         ^~~~~~~~~~~~
         "X11/Xlib.h"
In file included from main.cpp:6:
In file included from ./files.cpp:39:
In file included from /usr/local/include/Imlib2.h:26:
/usr/local/include/X11/Xlib.h:44:10: fatal error: 'X11/X.h' file not found
#include <X11/X.h>
         ^~~~~~~~~
2 errors generated.
to find Xlib.h
Code: 
[userx@FreeBSD64ssd project]$ find / -type f -name Xlib.h
find: /usr/local/share/polkit-1/rules.d: Permission denied
find: /usr/local/etc/polkit-1/rules.d: Permission denied
find: /usr/local/etc/polkit-1/localauthority: Permission denied
find: /usr/local/etc/cups/ssl: Permission denied

/usr/local/include/X11/Xlib.h

find: /usr/local/var/db/tpm: Permission denied
find: /usr/local/var/lib/tpm: Permission denied
find: /media/ada1s5/lost+found: Permission denied
find: fts_read: No such file or directory

so maybe that is why my entire program is crashing. being that Imlib2.h is using Xlib.h and it is not in the standard location it gets that fault, how to side track that?
Code: 
[userx@FreeBSD64ssd project]$ c++ I/usr/local/include/X11/Xlib.h    main.cpp
c++: warning: treating 'c-header' input as 'c++-header' when in C++ mode, this behavior is deprecated [-Wdeprecated]
c++: error: no such file or directory: 'I/usr/local/include/X11/Xlib.h'
 
AH this might be a nevermind,
Code: 
-I/usr/local/include
I hate wasting paper. even e-paper

mod:

now its boot libs issue
 
it's not solved, but I pulled out my bascily the same program, this one is written in C and not C++, and it works.

I guess FreeBSD got a little more to do to get boost to work in ones personal projects?
 
No. Boost works pretty well on FreeBSD.
What did your debugger tell you?
 
Run the program in gdb and see what is crashing. That is so much faster to find a problem...
 
Crivens said:
Run the program in gdb and see what is crashing. That is so much faster to find a problem...
Click to expand...
In lue of trying to figure out how to get kdbg to start my program.
Code: 
[userx@FreeBSD64ssd mh5000-1.3.5]$ ./mh5000 -over-drive -O /media/data1/wallhaven-papers
ld-elf.so.1: Shared object "libboost_system.so.1.70.0" not found, required by "mh5000"
installed
Code: 
[userx@FreeBSD64ssd mh5000-1.3.5]$ sudo pkg info boost-libs
boost-libs-1.71.0
Name           : boost-libs
Version        : 1.71.0
Installed on   : Tue Sep  3
recompiled it
Code: 
[userx@FreeBSD64ssd mh5000-1.3.5]$
[userx@FreeBSD64ssd mh5000-1.3.5]$ make clean
rm mh5000 *.o
[userx@FreeBSD64ssd mh5000-1.3.5]$ make
g++  -O2 -pipe -std=c++14 -c files.cpp -o files.o
g++  -O2 -pipe -std=c++14 -c img.cpp -o img.o
g++  -O2 -pipe -std=c++14 -c imgfunctions.cpp -o imgfunctions.o
g++  -O2 -pipe -std=c++14 -c options.cpp -o options.o
g++  -O2 -pipe -std=c++14 -c timers.cpp -o timers.o
g++  -O2 -pipe -std=c++14 -c main.cpp -o main.o
g++ -O2 -pipe -std=c++14 -lm -lX11 -lImlib2 -I/usr/local/include -o mh5000 files.o img.o imgfunctions.o options.o timers.o main.o  -Wno-switch-enum -Wno-switch -lboost_system -lboost_filesystem
[userx@FreeBSD64ssd mh5000-1.3.5]$ ./mh5000 -over-drive -O /media/data1/wallhaven-papers
Segmentation fault (core dumped)

as far as a debugger, I do not know how to get the command line args into it to start it or whatever it is sying it wants.
GDB(I18N_ARGUMENT_MISSING) exited unexpectedly.

Restart the session (e.g. with File|Load Executable).
Click to expand...

shrugs shoulders
Code: 
[userx@FreeBSD64ssd mh5000-1.3.5]$ gdb mh5000 -over-drive -O /media/data1/wallhaven-papers
ld-elf.so.1: Shared object "libboost_regex.so.1.70.0" not found, required by "gdb"
 
1. Read the fine manual. For gdb, that is man gdb.

2. Use c++, not g++.

3. Add '-g' to the makefile at the correct place. The man page should tell you more.

4. Maybe simply use the binary and a core dump for a post mortem analysis.

5. Forget about printf-debugging for most of the cases.
 
Crivens said:
1. Read the fine manual. For gdb, that is man gdb.

2. Use c++, not g++.

3. Add '-g' to the makefile at the correct place. The man page should tell you more.

4. Maybe simply use the binary and a core dump for a post mortem analysis.

5. Forget about printf-debugging for most of the cases.
Click to expand...
yeah you got me in that switch to c++, I reopened a new tar of it, and forgot to replace that.

did you notice that boost lib version always switching from 70 to 71.

-g : going to have to find out what that is. debugging...
 
well with me notcing the quick changes in versions of boost every time I install something to help me figure this out, and the loss of some apps along the way, having to re-install them.

I just installed codeblocks and put my app back into development mode and see what I can do about a rewrite of the part that using the filesystem. using just gcc and remove boost-filesystem.
 
Using gcc9 I replaced its internal functions from boosts.
Now it works in FreeBSD too.
I just need to bounce into Linux and compile it to see if it still works in there too.
Code: 
#if __FreeBSD__
#include </usr/local/include/X11/Xlib.h>
#include </usr/local/include/Imlib2.h>
#elif __linux
#include </usr/include/Imlib2.h> //Imlib_Load_Error
#endif // __FreeBSD__
and
Code: 
/**
** Removed to be replaced with gcc filesystem

using namespace boost::filesystem;

namespace filesys = boost::filesystem;
*/
using namespace std::filesystem;
namespace filesys = std::filesystem;

struct recursive_directory_range
{
    typedef recursive_directory_iterator iterator;
    recursive_directory_range(path p) : p_(p) {}

    iterator begin() { return recursive_directory_iterator(p_); }
    iterator end() { return recursive_directory_iterator(); }

    path p_;
};
//use to be boost::filesystem::path
size_t loadFiles(std::vector<std::string> &mylist , std::filesystem::path p)
{

// for (auto it : recursive_directory_range(p))
for (auto it : filesys::recursive_directory_iterator(p) )
  {
      //convert char to string
      std::stringstream newStringPath;
      newStringPath << it;
      std::string myStringPath = newStringPath.str();

    if (  checkFileExt(getFileExt(myStringPath)) == 1 )
    {
         // Remove all double-quote characters
        myStringPath.erase(
        remove( myStringPath.begin(), myStringPath.end(), '\"' ),
        myStringPath.end() );

        mylist.push_back( myStringPath );
    }
}
return 0;
}

BACK:

I get this.
Code: 
XIO:  fatal IO error 0 (No error: 0) on X server "unix:0.0"
      after 86 requests (85 known processed) with 0 events remaining.
It prob has something to do with xorg display when setting another image. But this is for another day/post.
 
By the way, why are you using gcc? FreeBSD uses Clang as the default C / C++ compiler. Is there a strong reason to not use the default?
 
It strikes me as odd that someone juggles namespaces and frameworks, but does not know how a debugger is used. Stack overflow? Maybe the way of the world these days.
 
ralphbsz said:
By the way, why are you using gcc? FreeBSD uses Clang as the default C / C++ compiler. Is there a strong reason to not use the default?
Click to expand...
it is just for this one program I wrote. as c++ did not work just typing c++ and gnu just did. Time consumption taken is less with gnu then to have to learn all of the nuts and bolts of Clang, and still have to figure out how to get three or four lines of code to work using clang.

I do not know much about Clang, only that I've read of it.
 
Crivens said:
It strikes me as odd that someone juggles namespaces and frameworks, but does not know how a debugger is used. Stack overflow? Maybe the way of the world these days.
Click to expand...
yep, said the kid that leaned how to walk but never learned how to tie shoes. Penny Loafers where always his choice.

it is not as hard or puzzling as one might think, if one puts there mind to it. My coding experiences is not even so extensive as that I have written something I could not figure it out, by not having to use a debugger.

I've never had any luck, and perhaps patience to read everything on how to use one to completely figure it out.
 
Crivens said:
You need to be strong now... https://lmgtfy.com/?q=ai+bug+fixing
Click to expand...
it wasn't that hard to figure out that it was the boost libs and fbsd conflict, and as I stated. Seeing fbsd keep swapping out versions of boost, and removing apps not even related to this issue, they just used boost too and them apps ran into boost version conflicts because fbsd kept removing one version to add a different one to conform with what I was installing to "help" me figure out the issue I was having to debug the issue now made obvious, then seeing that gnu added what I was using from boost into there stuff finally. I used that instead that problem solved without the use of a debugger.

now it is a x issue and I bet it has something to do with how fbsd uses x and its display. where in Linux it has a limit of displays opened, and its garbage collection is that like Java, it happens wherever it happens. there is no real control of it in order to free up memory in the case of Java.
 
I don't get it, it is so much unlike my first steps...
I first learned assembler and then a higher level language. Mostly by looking at what the compiler did with my code. Not wanting to know what is below the surface? No.

You compile with debug symbols (-g) and run your code. When hello gives you a core dump, hello.core, you do gdb ./hello ./hello.core and look at what is the cause. The cause is NOT that FreeBSD tracks versions of boost but that someone is using unportable code or relies on edge cases. Both is a big NoNo, but it is easier to get away with it someplace else compared to us here...
So I suggest you find the real problem and learn the why, not the avoid.
 
Crivens said:
I don't get it, it is so much unlike my first steps...
I first learned assembler and then a higher level language. Mostly by looking at what the compiler did with my code. Not wanting to know what is below the surface? No.

You compile with debug symbols (-g) and run your code. When hello gives you a core dump, hello.core, you do [cmd gdb ./hello ./hello.core[/cmd] and look at what is the cause. The cause is NOT that FreeBSD tracks versions of boost but that someone is using unportable code or relies on edge cases. Both is a big NoNo, but it is easier to get away with it someplace else compared to us here...
So I suggest you find the real problem and learn the why, not the avoid.
Click to expand...
thanks for the advice, it is just a program I just wanted to see if it would work in fbsd as well, just because I wrote it for Linux and to satisfy my sense of curiosity.

though seeing this fbsd giving me dump files is a curiosity.

as far as boost, it to me seemed like if installed as a pkg vs compiled from ports. it was giving me that boost version conflict.

my program, it does not keep track of the Governments movements within the world, or anything special like that.

it is not a mission critical program, it is only complex in the many ways it can set an image to the background, and changing the images dimensions, and colors to be used as a border around an image(s) before setting it to the background (wallpaper), and change images at a user given time. Which are all covered up mostly by other windows to other more important apps to be used within an operating system.
 
You must log in or register to reply here.
Back
Top