The qt program deployed by ubuntu20.04 does not work.
./test: error while loading shared libraries: libQt5Network.so.5: cannot open shared object file: No such file or directory
(LD_LIBRARY_PATH works fine. However, LD_LIBRARY_PATH should not be used.)
The qt program deployed by ubuntu18.04 works well without any problems.
(Use rpath and qt.conf without LD_LIBRARY_PATH)
I don't know why the Qt program deployed by ubuntu20.04 can't find some Qtlibs.
libQt5Gui.so.5 => /home/admin/EXE_2004/./qt/lib/libQt5Gui.so.5 (0x00007f260b2cc000)
libQt5Xml.so.5 => /home/admin/EXE_2004/./qt/lib/libQt5Xml.so.5 (0x00007f260b28a000)
libQt5Sql.so.5 => /home/admin/EXE_2004/./qt/lib/libQt5Sql.so.5 (0x00007f260b23a000)
libQt5Core.so.5 => /home/admin/EXE_2004/./qt/lib/libQt5Core.so.5 (0x00007f260acf1000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f260aaff000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f260aae4000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f260a8f2000)
libQt5Network.so.5 => not found
libpulse.so.0 => /lib/x86_64-linux-gnu/libpulse.so.0 (0x00007f260a89b000)
Is there a good solution?
Thank you.
Related
I want to use SQLITE for my laravel5 project on my webserver. I migrated my local laravel 5 project onto my AWS ec2 lamp Ubuntu server. http://realtoraxe.com/realtoraxe/public/ but it shows
InvalidArgumentException in SQLiteConnector.php line 34: Database does not exist.
I changed the database.php set for sqlite
<?php
return array(
'default' => 'sqlite',
'connections' => array(
'sqlite' => array(
'driver' => 'sqlite',
'database' => 'http://realtoraxe.com/realtoraxe/storage/database.sqlite',
'prefix' => '',
),
),
);
?>
and I changed the .env to
APP_ENV=local
APP_DEBUG=true
APP_KEY=mystring
DB_CONNECTION=sqlite
CACHE_DRIVER=file
SESSION_DRIVER=file
when I do
php artisan migrate
it says there is no database
I think what I wrote as the path for the database in the database.php is wrong and do I may need to somehow write where my ip adress is in the .env file? I have been googling all night and can't seem to figure this out.
You dont need to edit the .php files at all. You can all do it in the .env file, since the files in the config directory are written to first use the values from the .env file, and if they are not defined, fall back on what is defined there.
env('DB_CONNECTION','mysql') would yield the value from the .env file, and only if it is not defined fall back to mysql.
So in your .env file just put the following:
DB_CONNECTION=sqlite
DB_DATABASE=database/database.sqlite
and create a file called database.sqlite in your database directory (thats where its supposed to be by convention.). That's it.
For default laravel 5.2+ installation:
create an sqlite database file
$ cd storage
$ touch database.sqlite
$ cd ..
make it writeable
$ chmod -R 777 storage
at ".env" file:
DB_CONNECTION=sqlite
DB_DATABASE=storage/database.sqlite
and remove or comment all other DB_* records
If you prefer to use relative path, instead of absolute to database file
at "config/database.php"
instead of:
'database' => env('DB_DATABASE', database_path('database.sqlite')),
write:
'database' => __DIR__ . '/../' . env( 'DB_DATABASE' ),
now, laravel app will be able to find sqlite file, and php artisan will work too
Why are you using HTTP link? I guess it should link to a .sqlite DB file:
'database' => __DIR__.'/../database/production.sqlite',
http://laravel-recipes.com/recipes/118/setting-up-the-sqlite-database-driver
Whenever I run php artisan migrate, the following error is shown in the console:
[PDOException]
SQLSTATE[HY000] [14] unable to open database file
The database.sqlite file is located at database/. I'm running Windows 10, Laravel 5.2. Here is .env file config:
.env:
DB_CONNECTION=sqlite
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=database
DB_USERNAME=homestead
DB_PASSWORD=secret
I have looked everywhere, but could not find what causes this error and how to resolve it.
Update
I managed to make migrations run successfully by replacing DB_DATABASE=database with DB_DATABASE=database/database.sqlite in .env file. However, new error occurs whenever I try to retrieve items from the database:
public function index()
{
// cause of the error
$cards = Card::all();
return view('cards.index', compact('cards'));
}
The above action throws following error:
InvalidArgumentException in SQLiteConnector.php line 34:
Database (database/database.sqlite) does not exist.
The strange thing is, that the command Card::all() works flawlessly in php artisan tinker mode. What kind of magic is that?
Anyway, I've also found out, that the line:
'database' => env('DB_DATABASE', database_path('database.sqlite')),
in database.php file needs to be replaced with just database_path('database.sqlite') and everything starts to work normally.
It seems, that the root of the problem is env('DB_DATABASE') call. I went to SQLiteConnector.php file and dumped the output of both env('DB_DATABASE') and database_path('database.sqlite'). Here are their outputs respectively:
dd(env('DB_DATABASE')) // => 'database/database.sqlite'
dd(database_path('database.sqlite')) // => 'D:\www\project\database\database.sqlite'
As you see, their output differs, and the second one is what is expected. Is this a Laravel bug? Or did I misunderstood something?
Short Solution
Though not answering the question, the way to fix "Database not found" issue is to replace the following line in database.php:
'database' => env('DB_DATABASE', database_path('database.sqlite')),
with
'database' => database_path('database.sqlite'),
By using the relative path, migrations will fail because they use project directory as root directory...
To correct everything, I suggest setting:
DB_DATABASE=database\database.sqlite
and tweaking the sqlite connections in config/database.php as follows:
'database' => env('DB_DATABASE/..', database_path('database.sqlite')),
Original Answer
The .env file should contain this:
DB_DATABASE=..\database\database.sqlite
With some testing you can verify that the link included in DB_DATABASE
is relative to the 'public' directory (at least on my Windows machine). That's why we should introduce ..\ before your link.
And of course, using an absolute link should do it too:
DB_DATABASE=D:\www\project\database\database.sqlite
as #Josh suggests
Create file called database.sqlite in this folder as database/database.sqlite
Open the .env file and change MySQL to SQLite
Comment password and username and databaseName using '#'
run php artisan migrate enjoy
env file like this:
DB_CONNECTION=sqlite
#DB_HOST=127.0.0.1
#DB_PORT=3306
#DB_DATABASE=database
#DB_USERNAME=homestead
#DB_PASSWORD=secret
Complementing the awnser by our friend #alexander-lomia
Change:
'database' => env('DB_DATABASE', database_path('database.sqlite'))
To:
'database' => database_path(env('DB_DATABASE'))
in database.php
:)
Instead of a relative path you need to use an absolute path in your .env file.
DB_DATABASE=/var/www/project/database/database.sqlite
or in your case:
DB_DATABASE=D:\www\project\database\database.sqlite
I got the same problem as you did. You have to use the absolute path in ENV file.
Please check the official documentation about this https://laravel.com/docs/5.4/database
DB_CONNECTION=sqlite
DB_DATABASE=/absolute/path/to/database.sqlite
This worked for me in Laravel 5.5
In .env file just have the connection name and remove all other DB_ related settings: DB_CONNECTION=sqlite_testing
Define your sqlite settings in the config/database.php file:
'connections' => [
'sqlite_testing' => [
'driver' => 'sqlite',
'database' => database_path('testing-db.sqlite'),
'prefix' => '',
],
...
]
My file is in the database/testing-db.sqlite.
Shortest and easiest solution is to remove default mysql settings in .env and work in database.php. That's what worked for me at least.
Remove the following...
DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=homestead
DB_USERNAME=homestead
DB_PASSWORD=secret
I found the following works rather well, if you prefer to use relative paths:
replace the 'database' line under SQLite with the following:
'database' => database_path(env('DB_DATABASE', 'database.sqlite')),
This was the setting I had used,
'sqlite' => [
'driver' => 'sqlite',
'database' => database_path('database.sqlite'),
'prefix' => '',
'foreign_key_constraints' => env('DB_FOREIGN_KEYS', true),
],
I also had to run touch database.sqlite in the database folder.
The problem is that php artisan migrate will use the DB_DATABASE from the root of the project, while serving the project with php artisan serve will run from the public directory.
The best solution for me is to create a link to database inside public directory:
UNIX: ln -s database public/database
Windows: mklink /J public\database database
Of course then you would have to deny access to database folder from HTTP requests but that should be easily done.
I have a Qt / ROS / Qwt application. Everything was going fine until I tried to link to Qwt. Note that I'm using Qwt 6.1.2 which should run on Qt 5.5. Indeed, the examples run fine.
When I run my binary, it crashes even if I'm not using Qwt. I just need to link the my code to Qwt for that to happen. And -here is the issue I think-, gdb gives the following error:
ram received signal SIGSEGV, Segmentation fault.
0x00007ffff25eadfc in ?? () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
Which is wrong since the binary should be using Qt 5.5. To make things more weird, ldd gives:
>> ldd dls_gui | grep 'Qt'
libQt5Widgets.so.5 => /home/jcolmenares/Qt/5.5/gcc_64/lib/libQt5Widgets.so.5 (0x00007f684cadc000)
libQt5Gui.so.5 => /home/jcolmenares/Qt/5.5/gcc_64/lib/libQt5Gui.so.5 (0x00007f684afad000)
libQt5Core.so.5 => /home/jcolmenares/Qt/5.5/gcc_64/lib/libQt5Core.so.5 (0x00007f684a867000)
libQtSvg.so.4 => /usr/lib/x86_64-linux-gnu/libQtSvg.so.4 (0x00007f684862c000)
libQtGui.so.4 => /usr/lib/x86_64-linux-gnu/libQtGui.so.4 (0x00007f6847979000)
libQtCore.so.4 => /usr/lib/x86_64-linux-gnu/libQtCore.so.4 (0x00007f6847493000)
libicui18n.so.54 => /home/jcolmenares/Qt/5.5/gcc_64/lib/libicui18n.so.54 (0x00007f6844e33000)
libicuuc.so.54 => /home/jcolmenares/Qt/5.5/gcc_64/lib/libicuuc.so.54 (0x00007f6844a85000)
libicudata.so.54 => /home/jcolmenares/Qt/5.5/gcc_64/lib/libicudata.so.54 (0x00007f684305b000)
How can I be linked to both Qt5 and Qt4? Qwt seems to be linked to only Qt 5.5:
>> ldd /usr/local/qwt-6.1.2/lib/libqwt.so | grep 'Qt'
libQt5PrintSupport.so.5 => /home/jcolmenares/Qt/5.5/gcc_64/lib/libQt5PrintSupport.so.5 (0x00007fbcee13a000)
libQt5Svg.so.5 => /home/jcolmenares/Qt/5.5/gcc_64/lib/libQt5Svg.so.5 (0x00007fbcedee5000)
libQt5OpenGL.so.5 => /home/jcolmenares/Qt/5.5/gcc_64/lib/libQt5OpenGL.so.5 (0x00007fbcedc8e000)
libQt5Widgets.so.5 => /home/jcolmenares/Qt/5.5/gcc_64/lib/libQt5Widgets.so.5 (0x00007fbced410000)
libQt5Gui.so.5 => /home/jcolmenares/Qt/5.5/gcc_64/lib/libQt5Gui.so.5 (0x00007fbcecbfc000)
libQt5Core.so.5 => /home/jcolmenares/Qt/5.5/gcc_64/lib/libQt5Core.so.5 (0x00007fbcec4b7000)
libicui18n.so.54 => /home/jcolmenares/Qt/5.5/gcc_64/lib/libicui18n.so.54 (0x00007fbcea032000)
libicuuc.so.54 => /home/jcolmenares/Qt/5.5/gcc_64/lib/libicuuc.so.54 (0x00007fbce9c84000)
libicudata.so.54 => /home/jcolmenares/Qt/5.5/gcc_64/lib/libicudata.so.54 (0x00007fbce825a000)
My CMakeList.txt file is:
cmake_minimum_required(VERSION 2.8.11)
project(dls_gui)
# Find the QtWidgets library
find_package(Qt5Widgets)
# Find includes in corresponding build directories
set(CMAKE_INCLUDE_CURRENT_DIR ON)
# Qwt related
# list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_LIST_DIR}/cmake_packages")
# find_package(Qwt REQUIRED)
find_path(QWT_INCLUDE_DIR qwt.h HINTS /usr/local/qwt-6.1.2/include)
find_library(QWT_LIBRARY qwt /usr/local/qwt-6.1.2/lib/)
include_directories(${QWT_INCLUDE_DIR})
# catkin related
catkin_package()
find_package(catkin REQUIRED COMPONENTS roscpp sensor_msgs urdf)
include_directories( ${catkin_INCLUDE_DIRS} include)
# source, header and resources files list
set(CPP_SOURCES src/main.cpp src/mainwindow.cpp src/basewidget.cpp src/rosQtNode.cpp
src/joints_sliders.cpp src/superslider.cpp src/support_polygon.cpp)
set(CPP_HDRS include/mainwindow.h include/basewidget.h include/rosQtNode.hpp
include/joints_sliders.hpp include/superslider.hpp include/support_polygon.hpp)
set(QRC_RESOURCES ${CMAKE_CURRENT_SOURCE_DIR}/dls_gui.qrc)
# Add the include directories for the Qt 5 Widgets module to# the compile lines.
include_directories(${Qt5Widgets_INCLUDE_DIRS} )
# Use the compile definitions defined in the Qt 5 Widgets module
add_definitions(${Qt5Widgets_DEFINITIONS})
# Generate headers from ui files
qt5_wrap_ui(UIS_HDRS src/mainwindow.ui)
# Generate moc files from cpp
qt5_wrap_cpp(MOC_SOURCES ${CPP_SOURCES} ${CPP_HDRS})
# Generate resources
qt5_add_resources(RESOURCES_RCC ${RESOURCE})
# Add compiler flags for building executables (-fPIE)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${Qt5Widgets_EXECUTABLE_COMPILE_FLAGS} -std=c++11")
## Ros include dirs
include_directories(include ${catkin_INCLUDE_DIRS})
# Tell CMake to create the helloworld executable
add_executable(dls_gui ${CPP_SOURCES} ${UIS_HDRS} ${MOC_SOURCES} ${QRC_RESOURCES})
add_executable(testRos src/testRos.cpp)
qt5_use_modules(dls_gui Widgets)
#Link the helloworld executable to the Qt 5 widgets library.
target_link_libraries(dls_gui ${QWT_LIBRARY} Qt5::Widgets ${catkin_LIBRARIES} )
target_link_libraries(testRos ${catkin_LIBRARIES})
I don't think this is ROS related, nevertheless, is important to say that the source code is compiled via catkin_make etc.
Last but not least, qmake refers to version 5.5:
>> qmake --version
QMake version 3.0
Using Qt version 5.5.0 in /home/jcolmenares/Qt/5.5/gcc_64/lib
EDIT: Just to be clear: I want (need) everything compiled and linked to the same Qt versión. But somehow, is not happening.
You need to link with qwt-qt5.
qwt is the Qt4 version of QWT, which uses libQtGui.so.4 etc., which you can see in your ldd output above. Linking with qwt-qt5 only requires Qt5 so files.
I switched everything back to Qt4. Got tired of wasting time on an issue that should not happen. Still have no idea how the binary ended linked to two different versions of Qt, only when linked to Qwt, where Qwt was linked only to Qt5 and the binary without the linkage to Qwt was also only linked to Qt5.
I've copied files and imported DB dump to MySQL on production server but when I try to access website settings.php file loads. I've got settings.php file in my site subdirectory in /sites folder. Here's it's content:
$databases = array('default' => array('default' => array(
'driver' => 'mysql',
'database' => 'dmitry_dkkb',
'username' => 'root',
'password' => 'fg67klbn0',
'host' => '127.0.0.1')));
I guess i just missed something when i edited this file
Try setting the drive to mysqli. Also, follow this steps:
1) Take a back up of your db and save it to a safe place
2) Remove all the tables from the db, and remove the setting.php or rename it
3) Do you clean install of Drupal using those files
4) Once finished, import the db back up
This process always works on all platforms, in all the situation
I'm using Drush 4.2 and I'm trying to rsync files from a the dev server to my local machine. My aliases.drushrc.php is located in the root of my local drupal installation and has the following in it:
$aliases['local'] = array(
'root' => '/Users/christian/Sites/site-root',
'path-aliases' => array(
'%files' => 'sites/default/files'
),
);
$aliases['dev'] = array(
'root' => '/var/www/vhosts/some-domain.com/subdomains/dev/httpdocs',
'remote-host' => 'some-domain.com',
'remote-user' => 'root',
'path-aliases' => array(
'%drush' => ' /var/tools/drush/drush',
'%files' => 'sites/default/files',
),
);
As a test I try to run this from the local drupal root:
drush rsync #dev:%files ~/Desktop/test/
I expect #dev:%files to expand to the remote file path but instead I get:
You will destroy data from /Volumes/MacintoshHD/Users/christian/Desktop/test/ and replace with data from #dev:/Volumes/MacintoshHD/Users/christian/Sites/site-root/%files
Any ideas?
UPDATE:
I've also found that when I'm try the command:
drush dd #dev:%files
I get
Target '#dev:%files' not found.
UPDATE 2
I've found that the issue seems to be coming from the location of the aliases.drushrc.php file. I had it in the drupal root of the site I was working on. I found that if I moved it to ~/.drush/ then everything worked perfectly.
I'd prefer to have it under source control though. I tried putting it in sites/default/ but it had the same problems as before. I'll award the bounty to whomever tells me where to put this file so it's under the source controlled site root.
You can set the alias path in your drushrc.php config file.
If this is not set, then drush searches these locations (in this order) for the alias file.
/etc/drush
drush installation folder
$HOME/.drush
insides the sites folder of your drupal site
Check the readme for more details.
BTW: You have a comma missing in your declaration of 'local' alias.
Modify it as:
'%files' => 'sites/default/files',