Build Fails on FreeBSD (posible other unix systems?) about sachesi HOT 17 CLOSED

I tried this:
diff --git a/src/main.cpp b/src/main.cpp
index 4115efe..a8841e3 100644
--- a/src/main.cpp
+++ b/src/main.cpp
@@ -95,7 +95,7 @@ Q_DECL_EXPORT int main(int argc, char *argv[])
viewer.show();

 int ret = app->exec();

-#if !defined(_WIN32) && !defined(BLACKBERRY) && !defined(ANDROID)
+#if !defined(_WIN32) && !defined(BLACKBERRY) && !defined(ANDROID) && defined(BOOTLOADER_ACCESS)
thread.quit();
thread.wait(4000);
#endif

Probably a hugly fix, but just so I move on for now :)

This leads me to a problem:
/usr/bin/ld: -f may not be used without -shared

from sachesi.

I will exclude BSD from the bootloader code. Thanks for report.
Does BSD have an alternative to libusb I could use?

from sachesi.

I believe so, see --> https://www.freebsd.org/cgi/man.cgi?format=html&query=libusb%283%29

And also (and if I'm not mistaken) the same functionality of linux's libdl is provided in FreeBSD's libc.

udev is ofc linux specific!

from sachesi.

OK, is the code similar enough to the current udev code? I could just enable a different codepath.

from sachesi.

Not sure, all I know is that in FreeBSD kernel there's devd instead of udev, but I only understand it from a sys admin perceptive honestly can't talk much about the code!

from sachesi.

Pushed a fix for the compile but will leave this issue open as I hope to have bootloader support for BSD in future.

from sachesi.

Thanks, the fix still includes "-ldl" "-luddev", I removed those in my local version (also changed the PREFIX to /usr/local/) and it builds, install and runs!

All seems to work fine (except backup and install ofc because of no USB connection)

from sachesi.

Backup and install should still work without libusb. Your Blackberry device just needs an IP address on your system.
On Linux, for example, this requires dhcpcd to be run on the device when it is detected as usbnet. Most distros have it set up to run this automatically. On FreeBSD, you would likely need to assign the IP address manually by running dhcp*(?).

Basically you should have the same functionality that Windows has right now.

from sachesi.

Or wait...
umodem0: <Research In Motion, Ltd. RIM Network Device, class 0/0, rev 2.00/2.40, addr 10> on usbus0
umodem0: data interface 0, has no CM over data, has no break
device_attach: umodem0 attach returned 6

Let me see what I get with this :)

Turn's out it works fine if I change the USB mode to Mac compatibly (auto or windows won't work)

ue0: flags=8843 metric 0 mtu 1500
ether 42:6f:2a:4d:86:c8
inet6 fe80::406f:2aff:fe4d:86c8%ue0 prefixlen 64 scopeid 0x5
inet 169.254.0.2 netmask 0xfffffffc broadcast 169.254.0.3
nd6 options=21

from sachesi.

Now the only issue is that when I go to backup it accepts the password, but when I click "load backup options" I get back to the password prompt with the message "there was an issue connecting".

Is there any flags to compile this with debug to see a more verbose output?

from sachesi.

Look for the commented out qDebug lines.
I should add a debug mode.

Yes, on Linux, Auto and Windows don't work. You have to manually choose Mac. Makes sense.

from sachesi.

Thank I'll look into that and recompile cause now it just core dumps and doesn't open...

this is what I get from gdb (no debug symbols ofc so probably not helpful)
(gdb) bt
#0 0x000000080385b8ab in QObject::~QObject ()
from /usr/local/lib/qt4/libQtCore.so.4
#1 0x000000080385b85f in QObject::~QObject ()
from /usr/local/lib/qt4/libQtCore.so.4
#2 0x000000000042f3bb in ?? ()
#3 0x0000000000443ee6 in ?? ()
#4 0x0000000000469bfd in std::__1::__basic_string_common::__throw_length_error ()
#5 0x0000000803860c0d in QMetaObject::activate ()
from /usr/local/lib/qt4/libQtCore.so.4
#6 0x0000000803456df0 in QNetworkReply::error ()
from /usr/local/lib/qt4/libQtNetwork.so.4
#7 0x00000008034565b0 in QSslSocket::qt_metacall ()
from /usr/local/lib/qt4/libQtNetwork.so.4
#8 0x000000080385c7ee in QObject::event ()
from /usr/local/lib/qt4/libQtCore.so.4
#9 0x000000080282146d in QApplicationPrivate::notify_helper ()
from /usr/local/lib/qt4/libQtGui.so.4
#10 0x0000000802822bda in QApplication::notify ()
from /usr/local/lib/qt4/libQtGui.so.4
#11 0x00000008038493a6 in QCoreApplication::notifyInternal ()
from /usr/local/lib/qt4/libQtCore.so.4
---Type to continue, or q to quit---
#12 0x0000000803849f85 in QCoreApplicationPrivate::sendPostedEvents ()
from /usr/local/lib/qt4/libQtCore.so.4
#13 0x0000000803876768 in QEventDispatcherGlib::QEventDispatcherGlib ()
from /usr/local/lib/qt4/libQtCore.so.4
#14 0x0000000804cf047e in g_main_context_dispatch ()
from /usr/local/lib/libglib-2.0.so.0
#15 0x0000000804cf0843 in g_main_context_pending ()
from /usr/local/lib/libglib-2.0.so.0
#16 0x0000000804cf08d4 in g_main_context_iteration ()
from /usr/local/lib/libglib-2.0.so.0
#17 0x0000000803875ef1 in QEventDispatcherGlib::processEvents ()
from /usr/local/lib/qt4/libQtCore.so.4
#18 0x00000008028c043d in QX11Info::isCompositingManagerRunning ()
from /usr/local/lib/qt4/libQtGui.so.4
#19 0x00000008038469cf in QEventLoop::exec ()
from /usr/local/lib/qt4/libQtCore.so.4
#20 0x000000080384995d in QCoreApplication::exec ()
from /usr/local/lib/qt4/libQtCore.so.4
#21 0x0000000000410bf9 in ?? ()
#22 0x00000000004104bf in ?? ()
#23 0x00000008006be000 in ?? ()
#24 0x0000000000000000 in ?? ()

from sachesi.

Thanks. Fixed that error. Apparently checking for nullptr isn't enough on QObject types.
By the way, edited with vim and pushed to git from my Android tablet :p.

from sachesi.

Awesome :D vim for android is quite nice actually :)

I've forked the repo and made this changes for BSD's https://github.com/mike-pt/Sachesi/commit/354dcf2625597a6d6f7997baf97ac2ac87288a86

The PREFIX however must be dealt with other way, this makes sense only for FreeBSD so I'm not doing the pull request for now, but the libs part are fine!

from sachesi.

Its working better now :)

Now I wonder without bootloader access I have no way to say upgrade from an autoloader package do I?

Btw the % status are not maching what the device says (and the debug messages) but I guess you know that!

from sachesi.

Well the bootloader code was never finished anyway so it doesn't matter.
Need to do more reverse-engineering.

Currently only way to run an Autoloader is on Windows.

from sachesi.

As bootloader code was never completed, this issue is no longer valid.

from sachesi.