On Solaris, when you compile a program that uses sockets, you need to link it with -lnsl -lsocket. Many such programs were originally written for Linux (where no extra libraries are needed), and therefore do not check for these libraries in their configure scripts, even though that is a rather simple addition. Something like this (untested):
AC_SEARCH_LIBS(gethostbyname, nsl, , AC_MSG_ERROR([gethostbyname not found]))
AC_SEARCH_LIBS(connect, socket, , AC_MSG_ERROR([connect not found]))
Is there a canonical way to do this check? Maybe even included in the autoconf distribution? You would imagine that there is a rather widespread need for that, but Google wouldn't tell me.
i think the closest to a canonical way to check this is the AX_LIB_SOCKET_NSL macro from the Autoconf Archive:
# ===========================================================================
# http://www.nongnu.org/autoconf-archive/ax_lib_socket_nsl.html
# ===========================================================================
#
# SYNOPSIS
#
# AX_LIB_SOCKET_NSL
#
# DESCRIPTION
#
# This macro figures out what libraries are required on this platform to
# link sockets programs.
#
# The common cases are not to need any extra libraries, or to need
# -lsocket and -lnsl. We need to avoid linking with libnsl unless we need
# it, though, since on some OSes where it isn't necessary it will totally
# break networking. Unisys also includes gethostbyname() in libsocket but
# needs libnsl for socket().
#
# LICENSE
#
# Copyright (c) 2008 Russ Allbery <rra#stanford.edu>
# Copyright (c) 2008 Stepan Kasal <kasal#ucw.cz>
# Copyright (c) 2008 Warren Young <warren#etr-usa.com>
#
# Copying and distribution of this file, with or without modification, are
# permitted in any medium without royalty provided the copyright notice
# and this notice are preserved.
AU_ALIAS([LIB_SOCKET_NSL], [AX_LIB_SOCKET_NSL])
AC_DEFUN([AX_LIB_SOCKET_NSL],
[
AC_SEARCH_LIBS([gethostbyname], [nsl])
AC_SEARCH_LIBS([socket], [socket], [], [
AC_CHECK_LIB([socket], [socket], [LIBS="-lsocket -lnsl $LIBS"],
[], [-lnsl])])
])
I can't remember any finished code off the top of my head, but you usually want to check whether you can link a program calling the gethostbyname() function without any extra libs first. Only if that fails, you want to try the nsl library.
Similar things apply e.g. for the m library.
Related
I have been trying to get this done for two days now. I have had different error to deal with. I am Using an M1 Apple Chip Mac pro and Xcode 13.4 and it has been difficult to get Sonarqube running. I finally found a docker image which is M1 specific and I have been able to get Sonarqube running locally.
My current challenge is having the test result sent to the Sonarqube project.
I have tried several method which includes
xcrun xccov view YourPathToThisFile/*.xccovreport --json
This script is not working even though I wanted an xml format.
Is there a better way to have the code coverage report sent to sonarqube. I have Sonarqube running but the test result and coverage is not showing. Sonarqube page currently says "The main branch has no lines of code."
NB: I am running Sonarqube with Docker
Below is my Sonarqube properties file.
#
# Swift SonarQube Plugin - Enables analysis of Swift and Objective-C projects into SonarQube.
# Copyright © 2015 Backelite (${email})
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU Lesser General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
#
# Sonar Server details
sonar.host.url=http://localhost:9000/
sonar.login=782a04fee8bfc7ae181f04bbd13734eb89e5580c
# sonar.password=admin
# Project Details
sonar.projectKey=tinggios
sonar.projectName=TinggIOSApp
sonar.projectDescription=This is TinggiOS
# Comment if you have a project with mixed ObjC / Swift
sonar.language=swift
sonar.projectKey=tinggios
sonar.qualitygate.wait=true
# Path to source directories
# sonar.sources=SonarDemo,SonarDemoTests,SonarDemoUITests
sonar.sources=.
# Exclude directories
sonar.test.inclusions=**/*Test*/**
sonar.test.inclusions=*.swift
sonar.exclusions=**/*.xml,Pods/**/*,Reports/**/*
# sonar.inclusions=*.swift
# Path to test directories (comment if no test)
sonar.tests=TinggIOS/Core/Tests/CoreTests,TinggIOS/Home/Tests/HomeTests,TinggIOS/OnboardingUITest
# Destination Simulator to run surefire
# As string expected in destination argument of xcodebuild command
# Example = sonar.swift.simulator=platform=iOS Simulator,name=iPhone 6,OS=9.2
# sonar.swift.simulator=platform=iOS Simulator,name=iPhone 7,OS=12.0
sonar.swift.simulator=platform=iOS Simulator,name=iPhone 11,OS=15
# Xcode project configuration (.xcodeproj)
# and use the later to specify which project(s) to include in the analysis (comma separated list)
# Specify either xcodeproj or xcodeproj + xcworkspace
sonar.swift.project=TinggIOS/TinggIOS.xcodeproj
sonar.swift.workspace=TinggIOS/TinggIOS.xcworkspace
sonar.language=swift
sonar.c.file.suffixes=-
sonar.cpp.file.suffixes=-
sonar.objc.file.suffixes=-
# Specify your appname.
# This will be something like "myApp"
# Use when basename is different from targeted scheme.
# Or when slather fails with 'No product binary found'
sonar.swift.appName=TinggIOS
# Scheme to build your application
sonar.swift.appScheme=TinggIOS
# Configuration to use for your scheme. if you do not specify that the default will be Debug
sonar.swift.appConfiguration=Debug
##########################
# Optional configuration #
##########################
# Encoding of the source code
sonar.sourceEncoding=UTF-8
# SCM
# sonar.scm.enabled=true
# sonar.scm.url=scm:git:http://xxx
# JUnit report generated by run-sonar.sh is stored in sonar-reports/TEST-report.xml
# Change it only if you generate the file on your own
# The XML files have to be prefixed by TEST- otherwise they are not processed
sonar.junit.reportsPath=sonar-reports/TEST-report.xml
# Cobertura report generated by run-sonar.sh is stored in sonar-reports/coverage-swift.xml
# Change it only if you generate the file on your own
sonar.swift.coverage.reportPattern=sonar-reports/coverage-swift*.xml
#sonar.coverageReportPaths=sonarqube-generic-coverage.xml
#sonar.swift.coverage.reportPattern=sonar-reports/cobertura.xml
# OCLint report generated by run-sonar.sh is stored in sonar-reports/oclint.xml
# Change it only if you generate the file on your own
sonar.swift.swiftlint.report=sonar-reports/*swiftlint.txt
# Change it only if you generate the file on your own
sonar.swift.tailor.report=sonar-reports/*tailor.txt
# Paths to exclude from coverage report (surefire, 3rd party libraries etc.)
# sonar.swift.excludedPathsFromCoverage=pattern1,pattern2
# sonar.swift.excludedPathsFromCoverage=.*Tests.*,
##########################
# Tailor configuration #
##########################
# Tailor configuration
# -l,--max-line-length=<0-999> maximum Line length (in characters)
# --list-files display Swift source files to be analyzed
# --max-class-length=<0-999> maximum Class length (in lines)
# --max-closure-length=<0-999> maximum Closure length (in lines)
# --max-file-length=<0-999> maximum File length (in lines)
# --max-function-length=<0-999> maximum Function length (in lines)
# --max-name-length=<0-999> maximum Identifier name length (in characters)
# --max-severity=<error|warning (default)> maximum severity
# --max-struct-length=<0-999> maximum Struct length (in lines)
# --min-name-length=<1-999> minimum Identifier name length (in characters)
sonar.swift.tailor.config=--no-color --max-line-length=100 --max-file-length=500 --max-name-length=40 --max-name-length=40 --min-name-length=4
I'm currently facing a problem with this team of 4.
Using binaries I downloaded on kiska's site. I'm able to compile cobol to C and run it with cobcrun or compile it to an executable. However I can 't get opencobol to find the postgres commands.
Here is the strat of my cobol script :
identification division.
program-id. pgcob.
data division.
working-storage section.
01 pgconn usage pointer.
01 pgres usage pointer.
01 resptr usage pointer.
01 resstr pic x(80) based.
01 result usage binary-long.
01 answer pic x(80).
procedure division.
display "Before connect:" pgconn end-display
call "PQconnectdb" using
by reference "dbname = postgres" & x"00"
by reference "host = 10.37.180.146" & "00"
returning pgconn
end-call
...
the call PQconnectdb fail with module ont found : PQconnectdb
I noticed that if i rename the libpq.dll the error message change to can't find entry point. So at least I'm sure it can get my dll.
After digging into the code of the call method of the libcob library. I found it it was possible to pre load some dll using an environment variable COB_PRE_LOAD but sitll no results.
Here is what look the script to compile the cobol :
call "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\amd64\vcvarsamd64.bat"
set COB_CONFIG_DIR=C:\OpenCobol\config
set COB_COPY_DIR=C:\OpenCobol\Copy
set COB_LIBS=%COB_LIBS% c:\OpenCobol\libpq.lib
set COB_LIBRARY_PATH=C:\OpenCobol\bin
set COB_PRE_LOAD=C:\OpenCobol\libpq.dll
#echo on
cobc -info
cobc -free -o pgcob -L:"C:\OpenCobol" -llibpq.lib test_cobol\postgres.cob
call cobcrun pgcob
I don't see anything missing, I'm using the 64-bit binaries from kiska's site and use the 64-bit cl.exe from Visual Studio, Postgres is a 64 bit version too (checked with dependencyChecker).
I even tryed to compile the generated C from Visual Studio, same result, but I may miss something, I'm pretty rotten in C and never really had to manage DLL or use Visual Studio.
What am I missing ?
COB_PRE_LOAD doesn't take any path or extension, see the short documentation for the available runtime configurations. I guess
set COB_LIBRARY_PATH=C:\OpenCobol\bin;C:\OpenCobol
set COB_PRE_LOAD=libpq
Will work. You can omit the C:\OpenCobol\bin if you did not placed any additional executables there.
If it doesn't work (even if it does) I'd try to get the C functions resolved at compile time. Either use
CALL STATIC "PQconnectdb" using ...
or an appropriate CALL-CONVENTION or leave the program as-is and use
cobc -free -o pgcob -L"C:\OpenCobol" -llibpq -K PQconnectdb test_cobol\postgres.cob
From cobc --help:
-K generate CALL to <entry> as static
In general: the binaries from kiska.net are quite outdated. I highly suggest getting newer ones from the official download site or ideally build them on your own from source, see the documentation for building GnuCOBOL with VisualStudio.
I'm currently on a project with my Raspberry Pi B+.
I'm using a DHT22 - Temperature & Humidity Sensor. I'm also using Adafruit that's working together with python.
My Problem is, that I don't really know, how to read out a specific thing in my .php script that I want to implement in a index.php (Apache-Server).
I can read the Temperature & Humidity over putty with:
sudo /root/Adafruit_Python_DHT/examples/AdafruitDHT.py 22 4
while 22 is the DHT "22" Sensor - since there is an older one named "11" and 4 the GPIO of the raspberry.
putty is now telling this:
root#raspberrypi:~# sudo /root/Adafruit_Python_DHT/examples/AdafruitDHT.py 22 4
Temp=21.3* Humidity=41.6%
The AdafruitDHT.py for itself looks like this:
#!/usr/bin/python
# Copyright (c) 2014 Adafruit Industries
# Author: Tony DiCola
# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to deal
# in the Software without restriction, including without limitation the rights
# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
# copies of the Software, and to permit persons to whom the Software is
# furnished to do so, subject to the following conditions:
# The above copyright notice and this permission notice shall be included in all
# copies or substantial portions of the Software.
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
# SOFTWARE.
import sys
import Adafruit_DHT
# Parse command line parameters.
sensor_args = { '11': Adafruit_DHT.DHT11,
'22': Adafruit_DHT.DHT22,
'2302': Adafruit_DHT.AM2302 }
if len(sys.argv) == 3 and sys.argv[1] in sensor_args:
sensor = sensor_args[sys.argv[1]]
pin = sys.argv[2]
else:
print('usage: sudo ./Adafruit_DHT.py [11|22|2302] GPIOpin#')
print('example: sudo ./Adafruit_DHT.py 2302 4 - Read from an AM2302 connected to GPIO #4')
sys.exit(1)
# Try to grab a sensor reading. Use the read_retry method which will retry up
# to 15 times to get a sensor reading (waiting 2 seconds between each retry).
humidity, temperature = Adafruit_DHT.read_retry(sensor, pin)
# Un-comment the line below to convert the temperature to Fahrenheit.
# temperature = temperature * 9/5.0 + 32
# Note that sometimes you won't get a reading and
# the results will be null (because Linux can't
# guarantee the timing of calls to read the sensor).
# If this happens try again!
if humidity is not None and temperature is not None:
print('Temp={0:0.1f}* Humidity={1:0.1f}%'.format(temperature, humidity))
else:
print('Failed to get reading. Try again!')
sys.exit(1)
my .php looks like this:
<?php
$temp = exec('cat /root/Adafruit_Python_DHT/examples/AdafruitDHT.py |grep Temp=');
$temp = explode('Temp=',$temp);
$temp = round($temp,2);
echo $temp;
?>
I know that my first line is not correct like that.
But I don't know how to read out the live-temperature and live-Humidity. And I didn't know what to google for exactly.
edit 1:
with the following .php file, the site looks like this:
`
as you can see, it is only missing the output coming from the DHT22-sensor only.
If you do
cat /root/Adafruit_Python_DHT/examples/AdafruitDHT.py | grep Temp=
you are not running/executing the AdafruitDHT.py program, you are copying it contents (ie. the python program text) So what you will get back from the PHP exec is probably the matching line
print('Temp={0:0.1f}* Humidity={1:0.1f}%'.format(temperature, humidity))
Change that line to:
$temp = exec('python /root/Adafruit_Python_DHT/examples/AdafruitDHT.py | grep Temp=')
after making sure you are allowed to use a pipe (|) in a PHP exec call. (If not consider stripping the output of the script to only that what you want to have in PHP, dropping the | grep .... part).
For some reason this EDF example doesn't compile. I'm using GNAT I tried it in Windows 8.1, Debian no result.
with Ada.Real_Time, ada.Task_Identification,ada.Dispatching.EDF; use Ada.Real_Time, ada.Task_Identification,ada.Dispatching.EDF;
Procedure exemple_ordon is
Task tache_Periodique;
Task body tache_Periodique is
Echeance: Time_Span := Milliseconds(30); heure: Time;
Begin
heure:= Clock; Set_Deadline(Clock + Echeance);
Loop
heure := heure + Echeance;Delay_Until_And_Set_Deadline(heure,Echeance);
end loop;
End tache_Periodique;
Begin Null; End exemple_ordon ;
The error message:
gnatmake -d -PC:\Users\Awk\default.gpr exemple_ordon.adb
gcc -c -g -O2 -I- -gnatA C:\Users\Awk\exemple_ordon.adb
Edf is not supported in this configuration
compilation abandoned
gnatmake: "C:\Users\Awk\exemple_ordon.adb" compilation error
The message Edf is not supported in this configuration tells the story!
I don’t have access to any supported version of GNAT, but the file a-disedf.ads (the spec of Ada.Dispatching.EDF) in FSF GCC 4.9.0 contains the comment
-- This unit is not implemented in typical GNAT implementations that lie on
-- top of operating systems, because it is infeasible to implement in such
-- environments.
-- If a target environment provides appropriate support for this package,
-- then the Unimplemented_Unit pragma should be removed from this spec and
-- an appropriate body provided.
so it’s possible that AdaCore may provide an implementation for some of the more real-time targets (e.g. VxWorks) for their paying customers.
Do you have access to AdaCore’s academic program (GAP)?
If you really need EDF scheduling, Concurrency in Ada by Burns and Wellings has an example (I have the paperback second edition); you can pick it up cheaply at AbeBooks.
If you ‘just’ need information about general tasking, there are several sources listed at the Ada Information Clearinghouse.
Many people developing high-integrity real time software in Ada use the Ravenscar Profile.
I'm doing VPATH builds with automake. I'm now also using generated source, with SWIG. I've got rules in Makefile.am like:
dist_noinst_DATA = whatever.swig
whatever.cpp: whatever.swig
swig -c++ -php $^
Then the file gets used later:
myprogram_SOURCES = ... whatever.cpp
It works fine when $builddir == $srcdir. But when doing VPATH builds (e.g. mkdir build; cd build; ../configure; make), I get error messages about missing whatever.cpp.
Should generated source files go to $builddir or $srcdir? (I reckon probably $builddir.)
How should dependencies and rules be specified to put generated files in the right place?
Simple answer
You should assume that $srcdir is a read-only, so you must not write anything there.
So, your generated source-code will end up in $(builddir).
By default, autotool-generated Makefiles will only look for source-files in $srcdir, so you have to tell it to check $builddir as well. Adding the following to your Makefile.am should help:
VPATH = $(srcdir) $(builddir)
After that you might end up with a no rule to make target ... error, which you should be able to fix by updating your source-generating rule as in:
$(builddir)/whatever.cpp: whatever.swig
# ...
A better solution
You might notice that in your current setup, the release tarball (as created by make dist) will contain the whatever.cpp file as part of your sources, since you added this file to the myprogram_SOURCES.
If you don't want this (e.g. because it might mean that the build-process will really take the pregenerated file rather than generating it again), you might want to use something like the following.
It uses a wrapper source-file (whatever_includer.cpp) that simply includes the generated file, and it uses -I$(builddir) to then find the generated file.
Makefile.am:
dist_noinst_DATA = whatever.swig
whatever.cpp: whatever.swig
swig -c++ -php $^
whatever_includer.cpp: whatever.cpp
myprogram_SOURCES = ... whatever_includer.cpp
myprogram_CPPFLAGS = ... -I$(builddir)
clean-local::
rm -f $(builddir)/whatever.cpp
whatever_includer.cpp:
#include "whatever.cpp"
Usually, you want to keep $srcdir readonly, so that if for instance the source is distributed unpacked on a CDROM, you can still run /.../configure from some other part of the file-system.
However if you are using SWIG to generate source code for a wrapper library, you probably want to distribute that SWIG-generated code as well so that your users do not need to install SWIG to compile your code. Then you have indeed a choice: you can decide that the SWIG-generated code should end in $builddir (it's OK: make dist will collect it there and include it in the tarball), or you could decide to output SWIG-generated code in $srcdir since it is really a source from the point of view of the distributed package. An advantage of keeping it in $srcdir is that when make distcheck attempts to build your package from a read-only source directory, it will fail on any attempt to call SWIG to regenerate the wrapper source. If you have your wrapper source in $builddir, you might not notice you have some broken rule that cause SWIG to be run on the user's host; by generating in $srcdir you ensure that SWIG is not needed by your users.
So my preference is to output SWIG wrapper sources in $srcdir. My setup for Python wrappers looks as follows:
EXTRA_DIST = spot.i
python_PYTHON = $(srcdir)/spot.py # _PYTHON is distributed by default
pyexec_LTLIBRARIES = _spot.la
MAINTAINERCLEANFILES = $(srcdir)/spot_wrap.cxx $(srcdir)/spot.py
_spot_la_SOURCES = $(srcdir)/spot_wrap.cxx $(srcdir)/spot_wrap.h
_spot_la_LDFLAGS = -avoid-version -module
_spot_la_LIBADD = $(top_builddir)/src/libspot.la
$(srcdir)/spot_wrap.cxx: $(srcdir)/spot.i
$(SWIG) -c++ -python -I$(srcdir) -I$(top_srcdir)/src $(srcdir)/spot.i
# Handle the multi-file output of SWIG.
$(srcdir)/spot.py: $(srcdir)/spot.i
$(MAKE) $(AM_MAKEFLAGS) spot_wrap.cxx
Note that I use $(srcdir) for all targets, because of limitations of the VPATH feature on various flavors of make. My setup to deal with the multiple files output by SWIG could be improved, but as these rules are not run by users and it has never caused me any problem, I do not bother.