There's a project that lets you snoop on memcached activity via pcap, and display the results in top/htop manner.
https://github.com/tumblr/memkeys.git
To build, you need autoconf and automake, and you configure the program for your system by running the supplied autogen.sh script.
When I run this, after a couple of dozen lines, it dies with the following output:
...
checking for g++44... no
checking for g++... no
checking for gcc... gcc
checking whether the C++ compiler works... no
configure: error: in `/data/tmp/memkeys/memkeys-master':
configure: error: C++ compiler cannot create executables
See `config.log' for more details
The config.log file indicates that Configure generated a C program with an error (I have gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3) installed):
configure:3191: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "memkeys"
| #define PACKAGE_TARNAME "memkeys"
| #define PACKAGE_VERSION "0.1"
| #define PACKAGE_STRING "memkeys 0.1"
| #define PACKAGE_BUGREPORT "bmatheny#mobocracy.net"
| #define PACKAGE_URL ""
| #define PACKAGE "memkeys"
| #define VERSION "0.1"
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
It looks like a statement was meant to be generated before the return statement, but nothing was inserted and the source is left with a lone semi-colon.
Does this ring a bell?
Ok, for archeologists who stumble across this problem in the future, the answer is that the server in question wasn't entirely set up for development (and Configure wasn't able to identify the problem correctly).
apt-get install build-essential
was the missing piece. If you want to deploy the resulting dynamic binary across a series of Ubuntu hosts, you'll also need to ensure that the libpcrecpp0 package is installed on them.
Related
I'm trying to create a bitbake recipe to build some source code that resides in a local folder (as opposed to fetching from a remote repo).
After running bitbake, I expect to have an executable file and a shared library in the resulting image.
The source code includes three CMakeLists.
So far, I'm able to:
Run cmake by itself to build the source code on my host and on the target (i.e. not using bitbake)
Using my .bb file, correctly point to the source code by using the variable OECMAKE_SOURCEPATH.
start running cmake using the default do_compile()
The build fails during do_compile() with the error:
In file included from /home/myname/UDS_Server_Integration/src/3rdparty/udsdoip/UDSSrvonDOIP/DoIPSrvProcess/Inc/typedefs.h:29,
| from /home/myname/UDS_Server_Integration/src/3rdparty/udsdoip/UDSSrvonDOIP/DoIPSrvProcess/Src/DOIP/DOIP.h:32,
| from /home/myname/UDS_Server_Integration/src/3rdparty/udsdoip/UDSSrvonDOIP/DoIPSrvProcess/Src/ISOUDS/ISOUDS_MAIN/ISOUDS_Server_Cfg.h:30,
| from /home/myname/UDS_Server_Integration/src/3rdparty/udsdoip/UDSSrvonDOIP/DoIPSrvProcess/Src/ISOUDS/ISOUDS_ClearDiagInfo/ISOUDS_ClearDiagInfo_Cfg.c:25:
| /home/myname/project/nxp_s32/build_s32g274asbc2/tmp/work/aarch64-ms-linux/embitel-uds/1.0.0-r0/recipe-sysroot-native/usr/lib/aarch64-ms-linux/gcc/aarch64-ms-linux/10.2.0/include/stdint.h:9:16: fatal error: stdint.h: No such file or directory
| 9 | # include_next <stdint.h>
| | ^~~~~~~~~~
| compilation terminated.
| make[2]: *** [CMakeFiles/uds-server.dir/build.make:264: CMakeFiles/uds-server.dir/src/3rdparty/udsdoip/UDSSrvonDOIP/DoIPSrvProcess/Src/ISOUDS/ISOUDS_ClearDiagInfo/ISOUDS_ClearDiagInfo_Cfg.c.o] Error 1
| In file included from /home/myname/UDS_Server_Integration/src/3rdparty/udsdoip/UDSSrvonDOIP/DoIPSrvProcess/Inc/typedefs.h:29,
| from /home/myname/UDS_Server_Integration/src/3rdparty/udsdoip/UDSSrvonDOIP/DoIPSrvProcess/Src/DOIP/DOIP.h:32,
| from /home/myname/UDS_Server_Integration/src/3rdparty/udsdoip/UDSSrvonDOIP/DoIPSrvProcess/Src/ISOUDS/ISOUDS_MAIN/ISOUDS_Server_Cfg.h:30,
| from /home/myname/UDS_Server_Integration/src/3rdparty/udsdoip/UDSSrvonDOIP/DoIPSrvProcess/Src/ISOUDS/ISOUDS_CntrlDTCSetting/ISOUDS_CntrlDTCSetting.c:13:
| /home/myname/project/nxp_s32/build_s32g274asbc2/tmp/work/aarch64-ms-linux/embitel-uds/1.0.0-r0/recipe-sysroot-native/usr/lib/aarch64-ms-linux/gcc/aarch64-ms-linux/10.2.0/include/stdint.h:9:16: fatal error: stdint.h: No such file or directory
| 9 | # include_next <stdint.h>
| | ^~~~~~~~~~
However, stdint.h does exist. I looked up what "include_next" is and it's a "wrapper header". I think GCC is using this to modify the headers for the target environment, i.e. this is a cross-compiler issue. I assume this would indicate that cmake is not configured correctly for cross-compilation, or not looking in the correct location for the modified headers.
I have never encountered this problem building other source code for the same target environment using the same cross-compiler. My .bb recipe is also written using the same variables as for other packages. I even compared the CMakeOutput.log and CMakeCache.txt for this failing recipe and other successful recipes and saw that most of the relevant variables were set with the same values.
This led me to believe this could be an issue with the CMakeLists.txt and not having configured cmake correctly for this particular source code.
I have tried adding -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 based on this thread.
I have also avoided directly setting the cross-compiler based on this.
However, I'm at a loss for what I could be missing.
Other issues I've referenced:
Referencing gcc with yocto recipe Makefile, unable to find stdint
Here are my CMakeLists for reference:
cmake_minimum_required(VERSION 3.13)
project("MyUDS"
VERSION "1.0.0"
LANGUAGES C)
include(GNUInstallDirs)
## --- C++ build flags ---
set(CMAKE_C_STANDARD_REQUIRED ON)
set(CMAKE_C_EXTENSIONS OFF)
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
set(CMAKE_C_FLAGS "-MMD -MP -O4 -fcommon")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=gnu11")
# Set version
set(PROJECT_VERSION_MAJOR 0 CACHE STRING "")
set(PROJECT_VERSION_MINOR 0 CACHE STRING "")
set(PROJECT_VERSION_PATCH 0 CACHE STRING "")
set(PROJECT_VERSION_BUILD 0 CACHE STRING "")
# changes binary and library outputs to ./build/bin and ./build/lib
# set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/bin)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/lib)
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/lib)
add_library(uds-server SHARED)
set_target_properties(uds-server PROPERTIES
VERSION ${PROJECT_VERSION}
SOVERSION ${PROJECT_VERSION_MAJOR})
add_subdirectory(src/3rdparty/udsdoip)
----- CMakeLists in src/3rdparty/udsdoip ------
file(GLOB_RECURSE sched_sources ${CMAKE_CURRENT_SOURCE_DIR}/UDSSrvonDOIP/DoIPSrvProcess/Sched/*.c)
add_executable(udsserver ${sched_sources})
target_link_libraries(udsserver uds-server pthread)
target_include_directories(
udsserver
PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/UDSSrvonDOIP/DoIPSrvProcess/Inc
${CMAKE_CURRENT_SOURCE_DIR}/UDSSrvonDOIP/DoIPSrvProcess/Sched/Inc
...
${CMAKE_CURRENT_SOURCE_DIR}/UDSSrvonDOIP/DoIPSrvProcess/Src/Inc
)
add_subdirectory(UDSSrvonDOIP/DoIPSrvProcess)
install(TARGETS udsserver DESTINATION bin)
install(FILES ${CMAKE_CURRENT_SOURCE_DIR}/service/uds_server.sh DESTINATION bin)
install(FILES ${CMAKE_CURRENT_SOURCE_DIR}/service/uds_server.service
DESTINATION /etc/systemd/system
)
----- CMakeLists in UDSSrvonDOIP/DoIPSrvProcess ------
project(lib-uds-server)
# Enable helper debugging messages
target_compile_definitions(
uds-server PUBLIC DEBUG_SOCKCOMM DOIP_SERVER_PRINT_TCP_RX_PACKET_DATA DOIP_SERVER_PRINT_FOUND_NET_DEVS
)
file(GLOB_RECURSE isouds_sources RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} *.c)
target_sources(uds-server PRIVATE ${isouds_sources})
target_include_directories(
uds-server
PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/Inc
${CMAKE_CURRENT_SOURCE_DIR}/Sched
${CMAKE_CURRENT_SOURCE_DIR}/Sched/Inc
...
${CMAKE_CURRENT_SOURCE_DIR}/Src/ISOUDS/ISOUDSSecurDtaTrans
)
install(TARGETS uds-server
ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR})
Found the issue, and it's a bit of a dumb mistake.
I was not inheriting the CMake C flags set by Yocto that are needed for the cross-compile environment. So no matter what flags I added in my .bb recipe file, they were being overridden in the source code CMakeLists.txt.
Here, where I was setting the C flags, I was not inheriting Yocto's flags.
set(CMAKE_C_FLAGS "-MMD -MP -O4 -fcommon")
I should have used the existing flags and appended the ones specific to my source code like this:
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -MMD -MP -O4 -fcommon")
This got my build working.
I'm using setup.py to package my project. the structure is like:
foo -
|
|--foo/
| |
| |--first.py
| |--second.py
| |--...
|--README
|--requirements.txt
|--scripts/
| |
| |-script1.sh
| |-script2.py
|--service.py
|--setup.py
If I run the current setup.py, which is in accordance with the suggestions here: What is setup.py?
then in the venv/lib/python3.6/site-packages/foo and venv/lib/python3.6/site-packages/scripts I can see all python classes there. But service.py is absent. My question is how to modify the setup.py to include service.py into packaging such that I can find service.py at venv/lib/python3.6/site-packages/?
Thanks in advance!
For top level modules, such as service.py, to be included in the distributions, setuptools offers the py_modules parameter.
The setuptools documentation does not show it clearly, but it is the same as in (now deprecated) distutils:
https://docs.python.org/3/distutils/setupscript.html#listing-individual-modules
setuptools.setup(
# ...
py_modules=['service'], # no '.py'
)
Error I get:
error[E0433]: failed to resolve: could not find `openssl` in `backend`
--> ...\src\...\swagger-0.12.1\src\connector.rs:41:34
|
41 | native_tls::backend::openssl::TlsConnectorBuilderExt::from_openssl(ssl);
| ^^^^^^^ could not find `openssl` in `backend`
error[E0433]: failed to resolve: could not find `openssl` in `backend`
--> ...\swagger-0.12.1\src\connector.rs:85:34
|
85 | native_tls::backend::openssl::TlsConnectorBuilderExt::from_openssl(ssl);
| ^^^^^^^ could not find `openssl` in `backend`
Compiling hyper v0.2.1
error: expected identifier, found `"rustc-serialize"`
--> ...\hyper-0.2.1\src\lib.rs:129:14
|
129 | extern crate "rustc-serialize" as serialize;
| ^^^^^^^^^^^^^^^^^ expected identifier
Generated a server stub user swagger. Ran into issues where cargo couldn't find openssl, giving an error like 'custom build something openssl-sys 0.9.24'. This was a known issue and I overcame it by downloading vcpkg, and using vcpkg to download openssl. Then using environment variables to point to the download folder so cargo could use openssl. But now the error seems to be that openssl doesn't exist in backend?
It also seems to specific to windows, any ideas?
Tried changing the version of native-tls to the most up to date version but it doesn't seem to have an affect at all. It looks like swagger's dependencies need updating but I literally just generated this stub...
You've landed on a flaw from the Rust documentation tools; it picks up what is in a package, but doesn't show the limits.
The backend module definition is defined as:
#[cfg(any(target_os = "macos", target_os = "ios"))]
pub mod security_framework;
#[cfg(target_os = "windows")]
pub mod schannel;
#[cfg(not(any(target_os = "macos", target_os = "windows", target_os = "ios")))]
pub mod openssl;
In other words, the situation is the following:
If you are on linux (i.e. not macOS, not windows, not iOS), then openssl is available
If you are on windows, then schannel is available
If you are on MacOS or iOS security_framework is available
You should, however, not be trying to target a specific backend, as this defeats the purpose of the library. Instead of importing native_tls::backend::openssl::TlsConnectorBuilderExt, import native_tls::TlsConnectorBuilder and let it decide what backend you need.
This may be easier said than done, however, since by the looks of your error this is caused by a third-party library, which indicates that it was only tested on Linux.
I have downloaded a copy of the 1.1.0-RELEASE tagged source code for Spring RESTdocs, but "gradlew build" is failing during the test phase. 273 of 502 tests are failing with variations on this error:
org.springframework.restdocs.request.RequestPartsSnippetTests > requestPartsWithOptionalColumn[Markdown] FAILED
java.lang.AssertionError:
Expected: is adoc snippetPart | Optional | Description
---- | -------- | -----------
a | true | one
b | false | two
but: was:Part | Optional | Description
---- | -------- | -----------
a | true | one
b | false | two
The problem looks to be that the string "adoc snippet" is prefixed to the start
of the expected output. I don't think that's right, although I can see in the AbstractContentSnippetMatcher.describeTo() why it's happening and it doesn't look very conditional so maybe it's the test's actual result that's wrong?
I have made no changes to the source code* but I don't see other people reporting this problem, so I'm mystified. I'm entirely new to gradle. Is there some kind of config I need to set up to make the tests pass? Should I be using a different target?
(OK... 1 teensy change: I removed the new-line-at-end-of-file check from the checkStyle - I'm downloading from Github onto a Windows PC.)
The problem is that the files in the zip have Unix-style line endings but, when run on Windows, Checkstyle and the tests expect Windows-style line endings.
Typically a Windows Git client will take care of this for you by converting the line endings when you check out the code. For example, the default configuration of Git for Windows is to check code out with Windows-style line endings but commit changes with Windows-style line endings.
You may be able to find a Windows utility that will batch-convert the line endings from LF to CRLF. Failing that, it's probably easiest to install a Git client (such as Git for Windows that I linked to above), ensure it's configure to perform line ending conversion, and then:
> git clone https://github.com/spring-projects/spring-restdocs
> cd spring-restdocs
> gradlew build
I'm at a loss, I'm having issues creating a stored proc in my local Postgres server (postgres.app, Mac OS X 10.7), as so
$ psql
psql (9.3.0)
Type "help" for help.
dchaston=# CREATE OR REPLACE FUNCTION table_update()
dchaston-# RETURNS TRIGGER AS $$
dchaston$# BEGIN
dchaston$# NEW.last_edit = now();
dchaston$# RETURN NEW;
dchaston$# END;
dchaston$# $$ language 'plpgsql';
ERROR: could not access file "$libdir/plpgsql": No such file or directory
I've checked the following:
Languages installed:
dchaston=# select * from pg_language;
lanname | lanowner | lanispl | lanpltrusted | lanplcallfoid | laninline | lanvalidator | lanacl
---------+----------+---------+--------------+---------------+-----------+--------------+--------
internal | 10 | f | f | 0 | 0 | 2246 |
c | 10 | f | f | 0 | 0 | 2247 |
sql | 10 | f | t | 0 | 0 | 2248 |
plpgsql | 10 | t | t | 12019 | 12020 | 12021 |
(4 rows)
lib directory (and pkglibdir just in case):
$ pg_config --libdir
/Applications/Postgres.app/Contents/MacOS/lib
$ pg_config --pkglibdir
/Applications/Postgres.app/Contents/MacOS/lib
File present:
$ cd /Applications/Postgres.app/Contents/MacOS/lib; ls plpg*
plpgsql.so
DLSUFFIX set correctly:
lib/pgxs/src/Makefile.shlib:135: DLSUFFIX = .so
Have tried uninstalling and reinstalling, but made no difference. Any ideas?
Did you install multiple instances (multiple versions or multiple instances of the same version) of Postgres on the same box? Standard Postgres is not fit for that. Debian or Ubuntu have additional infrastructure to allow multiple versions in parallel. I don't know about OS X, though.
In standard Postgres the path for $libdir is compiled into the program. Multiple versions do not get along.
When you execute pg_config --pkglibdir, make sure it's the one associated with your installation. Run:
which pg_config
Minor notes:
9.3.0? It's recommended to always upgrade to the latest point-release, which is 9.3.2 at the moment. Maybe a current source fixes your problem.
Also check your settings whether you are using the $libdir you think you are using:
SELECT * FROM pg_settings WHERE name ~~* '%lib%';
Don't quote the language name 'plpgsql' (though it's tolerated). It's an identifier: plpgsql.
Use the plpgsql assignment operator :=. = is undocumented but tolerated.
Since Postgres 9.4 both := and = are documented.
Otherwise your function definition is fine. That's not the root of the problem:
CREATE OR REPLACE FUNCTION table_update()
RETURNS trigger AS
$func$
BEGIN
NEW.last_edit := now();
RETURN NEW;
END
$func$ LANGUAGE plpgsql;
This one is related to the accepted answer.
I started getting the problem with libdir on MacOS Catalina 10.15.7 while doing the brew update as the brew update failed in between and I noticed that Postgresql was one of the many packages that it was trying to update and the above answer provided a good hint about multiple installations.
I verified that there weren't any additional versions of postgresql installed on my system. So a simple restart of the service did the trick for me:
brew services restart postgresql#10
I use FreeBSD and found a simple way to solve the problem, just copied the library from another server and pasted it into /usr/local/lib/postgresql/, which is the way $libdir. Although the versions of PostgreSQL are different, everything is working and I had no problems again.