|
|
SMS Server Tools 3 Community |
Welcome, Guest. The forum is currently read-only, but will open soon. |
Fri Mar 14, 2025 11:14 |
Page: 1
Keywords: Mode: All keywords (AND) |
Tue Oct 16, 2012 08:10
|
unterwulf: If you use the same modem for receiving and sending its handler may be blocked until the script completion and because of that the handler doesn't check outgoing queue. (Just a guess. I haven't taken a look at the source code.)
After the script completion the modem handler finds both two messages in outgoing queue and sends them immediately.
If it is the case one probable solution can be to spawn a background job from your script, like the following:
if [ "$1" = "RECEIVED" ]; then
script_that_does_long_job.sh &
fi
|
Sat Oct 06, 2012 19:50
|
unterwulf: Just for the record, there has already been a topic about this bug. Here is the link http://smstools3.kekekasvi.com/topic.php?id=831.
|
Mon Mar 19, 2012 15:58
|
unterwulf: You found a bug. The process_id is a modem index in modem processes and [always hardcoded ;-)] -1 in the main smsd process. Because DEVICE is actually devices[process_id], DEVICE must never be used unconditionally in shared code. Here is a quick patch.
diff -pruN smstools3.orig/src/locking.c smstools3/src/locking.c
--- smstools3.orig/src/locking.c 2010-08-18 15:34:57.000000000 +0400
+++ smstools3/src/locking.c 2012-03-19 19:35:28.000000000 +0400
@@ -42,7 +42,8 @@ int lockfile( char* filename)
lockfile=open(lockfilename,O_CREAT|O_EXCL|O_WRONLY,0644);
if (lockfile>=0)
{
- snprintf(pid, sizeof(pid), "%i %s\n", (int)getpid(), DEVICE.name);
+ snprintf(pid, sizeof(pid), "%i %s\n", (int)getpid(),
+ (process_id == -1) ? "MAINPROCESS" : DEVICE.name);
write(lockfile, pid, strlen(pid));
close(lockfile);
sync();
|
Sun Mar 18, 2012 15:12
|
unterwulf: At first, as root:
1) echo /tmp/core.%p > /proc/sys/kernel/core_pattern
This is required because smsd changes its working directory to / on start and it won't be able to create core files unless it is run from the user root. The command above asks Linux kernel to create core files in the directory /tmp instead of the current working directory. Note that this parameter is global and will immediately affect all sessions.
Next, as a regular user:
2) Make sure that the maximum size of core files isn't zero using the command ulimit -c. If it is zero, set it to some reasonable value or unlimited with the command ulimit -c unlimited. Note that this parameter is local for current session. So...
3) Run smsd in the same session.
4) Reproduce segmentation fault.
5) Make sure that a core file has been created in /tmp.
6) Run gdb -c <core_file> <smsd_binary>
7) In GDB session, issue the command bt.
After that you should see a stack trace where the topmost function is the one where the segmentation fault happened.
|
Fri Mar 16, 2012 12:13
|
unterwulf: smsd cannot use UDP. But it doesn't matter, because it wouldn't help you anyway. Several servers cannot use the same modem with serial interface simultaneously even if it is available via network, just because the modem is designed to use the only connection.
Irrespective of protocol you would need to synchonize the servers to use the modem exclusively. And it doesn't look like a wise setup.
BTW, what is the reason not to use just the only server?
|
Tue Mar 06, 2012 09:13
|
unterwulf: As far as I know smsd has no such functionality available via command line. There is an option -D to decode 7-bit GSM strings, but it not the same as decoding PDU.
However, you can have decoded PDU as a side effect of pdu_from_file option.
See http://smstools3.kekekasvi.com/index.php?p=configure#m_pdu_from_file for details.
Please note, that to make use of this option without real modem you will need to use modem_disabled option as well.
p.s. Just to save your time, smsd unable to decode the PDU from your post. Here is what it tells:
Error: Cannot decode PDU, see text part for details.
From:
Received: 12-03-06 13:01:52
Subject: GSM1
Modem: GSM1
IMSI:
Report: no
Alphabet: ISO
Length: 497
PDU: 02910021320c9144776211850210003c7f319
Pos: ....^^~here(5)
First tried with PDU mode new (with CSA):
The PDU data (21) says that this is a sent message. Can only decode received messages.
Next tried with PDU mode old (without CSA):
PDU ERROR: Position 5,2: Invalid recipient address length: "00"
No success. This PDU cannot be decoded. There is something wrong.
If you are unsure, confused or angry, please view the GSM 03.40
(ETSI TS 100 901) and related documents for details of correct
PDU format. You can also get some help via the Support Website.
|
Mon Feb 20, 2012 15:10
|
unterwulf:
"decode_unicode_text = yes" turns on internal decoding of incoming messages and it works. Is any option for outgoing messages ?
The Alphabet header is a kind of alternative to that for outgoing messages. I took a quick look at the source code and it seems that UTF-8 is a supported yet not documented value. So try to add the following header to your messages:
Alphabet: UTF-8
|
Thu Feb 16, 2012 15:43
|
unterwulf: Hi sasso,
Could be it due to the hardware? May be I'm using an unsupported GSM modem or is it only a software depending?
At this point it is not a hardware problem for sure. This message is a result of failed memory allocation. As far as I can see the FreeBSD port builds smsd with statistics support enabled by default. It this case smsd uses libmm memory allocation function that I don't know too much about and have no idea why it can fail.
So as a first step I would suggest to build smsd without statistics support. In this case smsd will use plain old malloc().
|
Thu Feb 16, 2012 14:28
|
unterwulf: Hi kewes!
Take a look at http://smstools3.kekekasvi.com/index.php?p=localizing.
In short, obviously language file can be used to drop unwanted headers from the incoming messages.
For example the following language file will drop From_TOA and From_SMSC headers.
incoming = yes
From_TOA: = -
From_SMSC: = -
|
Wed Feb 15, 2012 08:15
|
unterwulf: Current smstools build system has no convenient cross-compiling/staging support, so I would suggest to create a patch for Makefile like this:
diff -pruN smstools3.orig/src/Makefile smstools3/src/Makefile
--- smstools3.orig/src/Makefile 2010-09-21 15:29:14.000000000 +0400
+++ smstools3/src/Makefile 2012-02-15 12:12:10.000000000 +0400
@@ -1,7 +1,10 @@
# In case of windows, use os_cygwin=yes setting in the configuration file (smsd.conf).
# Select your setup size:
-CFLAGS = -D NUMBER_OF_MODEMS=64
+CFLAGS = -D NUMBER_OF_MODEMS=1
+
+CFLAGS += $(USER_CFLAGS)
+LFLAGS += $(USER_LDFLAGS)
# Uncomment for Solaris
# CFLAGS += -D SOLARIS
@@ -12,10 +15,10 @@ CFLAGS = -D NUMBER_OF_MODEMS=64
CFLAGS += -D NOSTATS
# Comment this out if iconv is not available on the system
-#CFLAGS += -D USE_ICONV
+CFLAGS += -D USE_ICONV
# Uncomment this is iconv is used and it's not included in libc:
-#LFLAGS += -liconv
+LFLAGS += -liconv
# Uncomment this to force smsd to run in terminal mode
#CFLAGS += -D TERMINAL
And use the following in the package Makefile:
define Package/smstools3
[...]
DEPENDS:=+libiconv-full
endef
[...]
define Build/Compile
$(MAKE) -C $(PKG_BUILD_DIR) \
CC=$(TARGET_CC) \
USER_CFLAGS='$(TARGET_CFLAGS) $(EXTRA_CFLAGS) $(TARGET_CPPFLAGS) $(EXTRA_CPPFLAGS) -I$(STAGING_DIR)/usr/lib/libiconv-full/include' \
USER_LDFLAGS='$(TARGET_LDFLAGS) $(EXTRA_LDFLAGS) -L$(STAGING_DIR)/usr/lib/libiconv-full/lib'
endef
|
Tue Feb 14, 2012 16:26
|
unterwulf:
It decodes in something unreadable and I do not know type of encoding after this internal decoding. I tried this optoion in the past (and just now) - that is whi this option was commented out in my config
Looks like the internal decoder makes use of wctomb() that in turn depends on current locale (and on libc locale support). As an alternative option you can link smsd against libiconv. In this case resulting encoding will be UTF-8 for sure (as long as libiconv supports UCS-2BE and UTF-8).
In order to link against libiconv uncomment the following lines in the src/Makefile:
# Comment this out if iconv is not available on the system
CFLAGS += -D USE_ICONV
# Uncomment this is iconv is used and it's not included in libc:
LFLAGS += -liconv
|
Tue Feb 14, 2012 15:50
|
unterwulf:
Seems because I get Alphabet: UCS2 sms and this option has no effect - it should affect on ISO or GSM alphabet only like documentation tells. I just tried this option and there was no effect. Received message has been saved in UNICODEBIG (aka UCS-2BE in iconv).
My bad. Try decode_unicode_text instead.
http://smstools3.kekekasvi.com/index.php?p=configure#g_decode_unicode_text
|
Tue Feb 14, 2012 14:26
|
unterwulf:
I need received sms in UTF-8 if Alphabet is UCS2. To encode sms on PC I use "sms2unicode $2 | iconv -c -f UTF-16 -t UTF-8 >> $2.txt" in smsevent.
...
Pleace help me to encode SMS in UCS2 to UTF-8.
Why don't you use the incoming_utf8 option instead of this?
http://smstools3.kekekasvi.com/index.php?p=configure#g_incoming_utf8
|
Tue Feb 14, 2012 08:20
|
unterwulf:
B.t.w. Why smsd uses so mutch memory ? It is a biggest process on my router by memory usage. pppd eats less RAM. pppd is more feature rech program. I almost have no RAM margin after starting smsd.
Try to reduce NUMBER_OF_MODEMS in src/Makefile.
# Select your setup size:
CFLAGS = -D NUMBER_OF_MODEMS=1
|
Wed Feb 08, 2012 21:13
|
unterwulf: For those who still interested in using smsd with PORTech modems here is a patch that adds a new functionality required for that.
It introduces a number of new smsd.conf options, namely:
* telnet_crlf
* telnet_cmd
* telnet_cmd_prompt
Their meaning is quite straightforward. Here is a config that is known to work with at least PORTech MV-372:
[GSM1]
device = @<your_modem_IP>:23
telnet_crlf = yes
telnet_login = <your_login>
telnet_password = <your_password>
telnet_login_prompt = username:
telnet_password_prompt = password:
telnet_cmd_prompt = module1, module2, state1, state2, info.
telnet_cmd = module1
init = ATV1
Note, the init = ATV1. It is required to switch the device into verbose result code format mode, so it answers OK and ERROR instead of 0 and 4. It is required as smsd doesn't understand numeric codes. As an option you can store settings in the user profile via telnet like
ATV1
AT&W
and the use init = ATZ to restore these settings.
diff -pruN smstools3.orig/src/modeminit.c smstools3/src/modeminit.c
--- smstools3.orig/src/modeminit.c 2010-09-20 13:31:43.000000000 +0400
+++ smstools3/src/modeminit.c 2012-02-04 01:44:14.000000000 +0400
@@ -487,6 +487,7 @@ void negotiate_with_telnet(char *answer,
char command;
int got_option;
char option;
+ const char *eol = DEVICE.telnet_crlf ? "\r\n" : "\n";
idx = 0;
while (idx < *len)
@@ -543,14 +544,20 @@ void negotiate_with_telnet(char *answer,
if (DEVICE.telnet_login_prompt[0] && strstr(answer, DEVICE.telnet_login_prompt) && DEVICE.telnet_login[0])
{
if (DEVICE.telnet_login_prompt_ignore[0] == 0 || !strstr(answer, DEVICE.telnet_login_prompt_ignore))
- snprintf(response, sizeof(response), "%s\n", DEVICE.telnet_login);
+ snprintf(response, sizeof(response), "%s%s", DEVICE.telnet_login, eol);
}
else if (DEVICE.telnet_password_prompt[0] && strstr(answer, DEVICE.telnet_password_prompt) && DEVICE.telnet_password[0])
- snprintf(response, sizeof(response), "%s\n", DEVICE.telnet_password);
+ snprintf(response, sizeof(response), "%s%s", DEVICE.telnet_password, eol);
+ else if (DEVICE.telnet_cmd_prompt[0] && strstr(answer, DEVICE.telnet_cmd_prompt) && DEVICE.telnet_cmd[0])
+ snprintf(response, sizeof(response), "%s%s", DEVICE.telnet_cmd, eol);
if (*response)
+ {
+ *answer = 0;
+ *len = 0;
if ((size_t)write(modem_handle, response, strlen(response)) != strlen(response))
writelogfile(LOG_ERR, 1, "%s: Failed to send response (login/password).", title);
+ }
#undef IAC
#undef DONT
@@ -1259,7 +1266,8 @@ int initmodem(char *new_smsc, int receiv
retries++;
put_command("AT\r", answer, sizeof(answer), 1, EXPECT_OK_ERROR);
- if (!strstr(answer, "OK") && !strstr(answer, "ERROR"))
+ if (!strstr(answer, "OK") && !strchr(answer, '0') &&
+ !strstr(answer, "ERROR") && !strchr(answer, '4'))
{
if (terminate)
return 7;
@@ -1272,7 +1280,7 @@ int initmodem(char *new_smsc, int receiv
}
// 3.1.7: If it looks like modem does not respond, try to close and open the port:
- if (retries >= 5 && !strstr(answer, "OK"))
+ if (retries >= 5 && !strstr(answer, "OK") && !strchr(answer, '0'))
{
try_closemodem(1);
t_sleep(1);
@@ -1282,8 +1290,8 @@ int initmodem(char *new_smsc, int receiv
break;
}
}
- while (retries <= 10 && !strstr(answer,"OK"));
- if (!strstr(answer,"OK"))
+ while (retries <= 10 && !strstr(answer, "OK") && !strchr(answer, '0'));
+ if (!strstr(answer,"OK") && !strchr(answer, '0'))
{
// 3.1: more detailed error message:
p = get_gsm_error(answer);
@@ -1308,7 +1316,7 @@ int initmodem(char *new_smsc, int receiv
put_command(command, answer, sizeof(answer), 2, EXPECT_OK_ERROR);
- if (!strstr(answer,"OK"))
+ if (!strstr(answer,"OK") && !strchr(answer, '0'))
writelogfile(LOG_ERR, 1, "Modem did not accept the pre-init string");
}
diff -pruN smstools3.orig/src/smsd_cfg.c smstools3/src/smsd_cfg.c
--- smstools3.orig/src/smsd_cfg.c 2010-09-21 13:15:07.000000000 +0400
+++ smstools3/src/smsd_cfg.c 2012-02-05 01:16:20.000000000 +0400
@@ -335,11 +335,14 @@ void initcfg()
devices.keep_messages = 0;
devices.trust_spool = 1;
devices.smsc_pdu = 0;
+ devices.telnet_crlf = 0;
devices.telnet_login[0] = 0;
snprintf(devices.telnet_login_prompt, sizeof(devices.telnet_login_prompt), "%s", TELNET_LOGIN_PROMPT_DEFAULT);
snprintf(devices.telnet_login_prompt_ignore, sizeof(devices.telnet_login_prompt_ignore), "%s", TELNET_LOGIN_PROMPT_IGNORE_DEFAULT);
devices.telnet_password[0] = 0;
snprintf(devices.telnet_password_prompt, sizeof(devices.telnet_password_prompt), "%s", TELNET_PASSWORD_PROMPT_DEFAULT);
+ devices.telnet_cmd[0] = 0;
+ devices.telnet_cmd_prompt[0] = 0;
devices.signal_quality_ber_ignore = 0;
devices.verify_pdu = 0;
devices.loglevel_lac_ci = 6;
@@ -1647,6 +1650,12 @@ int readcfg()
startuperror(yesno_error, name, value);
}
else
+ if (strcasecmp(name,"telnet_crlf")==0)
+ {
+ if ((NEWDEVICE.telnet_crlf = yesno_check(ask_value(NEWDEVICE.name, name, value))) == -1)
+ startuperror(yesno_error, name, value);
+ }
+ else
if (strcasecmp(name,"telnet_login")==0)
strcpy2(NEWDEVICE.telnet_login, ask_value(NEWDEVICE.name, name, value));
else
@@ -1662,6 +1671,12 @@ int readcfg()
if (strcasecmp(name,"telnet_password_prompt")==0)
strcpy2(NEWDEVICE.telnet_password_prompt, ask_value(NEWDEVICE.name, name, value));
else
+ if (strcasecmp(name,"telnet_cmd")==0)
+ strcpy2(NEWDEVICE.telnet_cmd, ask_value(NEWDEVICE.name, name, value));
+ else
+ if (strcasecmp(name,"telnet_cmd_prompt")==0)
+ strcpy2(NEWDEVICE.telnet_cmd_prompt, ask_value(NEWDEVICE.name, name, value));
+ else
if (strcasecmp(name,"signal_quality_ber_ignore")==0)
{
if ((NEWDEVICE.signal_quality_ber_ignore = yesno_check(ask_value(NEWDEVICE.name, name, value))) == -1)
@@ -2367,14 +2382,17 @@ int startup_check(int result)
if (!value_in(devices[x].check_network, 3, 0, 1, 2))
wrlogfile(&result, "Device %s has invalid value for check_network (%i).", devices[x].name, devices[x].check_network);
- // 3.1.7: Devices cannot have the same port.
- for (y = 0; y < NUMBER_OF_MODEMS; y++)
+ if (!DEVICE_X_IS_SOCKET)
{
- if (y == x)
- continue;
- if (devices[y].name[0] && devices[y].device[0])
- if (strcmp(devices[y].device, devices[x].device) == 0)
- wrlogfile(&result, "Devices %s and %s has the same port ( device = %s ).", devices[x].name, devices[y].name, devices[x].device);
+ // 3.1.7: Devices cannot have the same port.
+ for (y = 0; y < NUMBER_OF_MODEMS; y++)
+ {
+ if (y == x)
+ continue;
+ if (devices[y].name[0] && devices[y].device[0])
+ if (strcmp(devices[y].device, devices[x].device) == 0)
+ wrlogfile(&result, "Devices %s and %s has the same port ( device = %s ).", devices[x].name, devices[y].name, devices[x].device);
+ }
}
#ifndef USE_ICONV
diff -pruN smstools3.orig/src/smsd_cfg.h smstools3/src/smsd_cfg.h
--- smstools3.orig/src/smsd_cfg.h 2010-09-20 15:11:26.000000000 +0400
+++ smstools3/src/smsd_cfg.h 2012-02-04 00:50:23.000000000 +0400
@@ -221,11 +221,14 @@ typedef struct
char stopstring[100]; // 3.1.7: Command(s) to send to the modem when a devicespooler is stopping.
int trust_spool; // 3.1.9
int smsc_pdu; // 3.1.12: 1 if smsc is included in the PDU.
+ int telnet_crlf;
char telnet_login[64]; // 3.1.12: Settings for telnet.
char telnet_login_prompt[64];
char telnet_login_prompt_ignore[64];
char telnet_password[64];
char telnet_password_prompt[64];
+ char telnet_cmd[64];
+ char telnet_cmd_prompt[100];
int signal_quality_ber_ignore; // 3.1.14.
int verify_pdu; // 3.1.14.
int loglevel_lac_ci; // 3.1.14.
|
Wed Feb 01, 2012 21:47
|
unterwulf: As per your log it looks like the device echoing data characters it receives. (The seaquake is a login, isn't it?) If so, it is strange that it has not negotiated this feature (if it has there would be something like "Telnet: Got WILL for 1 (0x01), answering DONT." in the log).
Nevertheless, smsd doesn't care about any telnet options, so I see the two options here:
1) Somehow force the device not to use telnet echoing (probably some settings via GUI)
2) Implement echoing support in smsd :-)
Not sure if I can help here, but who knows. At least I am interested in identifying the root cause of the issue, so drop me a gmail (the same login as on this forum) if you can provide access to the device.
|
Wed Feb 01, 2012 21:09
|
unterwulf: Take a look at the patch from another similar topic http://smstools3.kekekasvi.com/topic.php?post=4011#post4011.
|
Thu Dec 08, 2011 05:25
|
unterwulf: I have no such a modem, but I took a look at smsd behaviour during telnet negotiation using netcat as a telnet server and I see that smsd continuously sends telnet_login if there is no enough delay between login and password prompt.
So the session looks like:
smsd> AT
telnet> login:
smsd> <telnet_login>
telnet> Password:
smsd> <telnet_login>
telnet> anything else
smsd> <telnet_login>
This patch seems to fix this, but probably break something else ;-)
--- a/src/modeminit.c
+++ b/src/modeminit.c
@@ -545,8 +545,12 @@ void negotiate_with_telnet(char *answer, int *len)
snprintf(response, sizeof(response), "%s\n", DEVICE.telnet_password);
if (*response)
+ {
+ *answer = 0;
+ *len = 0;
if ((size_t)write(modem_handle, response, strlen(response)) != strlen(response))
writelogfile(LOG_ERR, 1, "%s: Failed to send response (login/password).", title);
+ }
#undef IAC
#undef DONT
And, of course, per the user manual you referenced to you need a configuration like the following:
telnet_login_prompt = username:
telnet_password_prompt = password:
init = module1
|
Wed May 11, 2011 18:49
|
unterwulf:
BTW, support of Solaris seems to be broken in 3.1.12, so I had to fix it somehow to test the building process.
What was that bug?
The issue was that Solaris' headers do not define the NAME_MAX macro.
# gmake
cd src && gmake -
gmake[1]: Entering directory `/home/vs/src/smstools3/src'
cc -D NUMBER_OF_MODEMS=64 -D NOSTATS -W -Wall -D_FILE_OFFSET_BITS=64
-c -o extras.o extras.c
extras.c: In function `getfile':
extras.c:522: error: `NAME_MAX' undeclared (first use in this function)
extras.c:522: error: (Each undeclared identifier is reported only once
extras.c:522: error: for each function it appears in.)
gmake[1]: *** [extras.o] Error 1
gmake[1]: Leaving directory `/home/vs/src/smstools3/src/smstools3/src'
gmake: *** [compile] Error 2
The definition of NAME_MAX is commented out in the Solaris' limits.h with
the following note:
/*
* POSIX 1003.1a, section 2.9.5, table 2-5 contains [NAME_MAX] and the
* related text states:
*
* A definition of one of the values from Table 2-5 shall be omitted
from the
* <limits.h> on specific implementations where the corresponding value
is
* equal to or greater than the stated minimum, but where the value can
vary
* depending on the file to which it is applied. The actual value
supported for
* a specific pathname shall be provided by the pathconf() (5.7.1)
function.
*
* This is clear that any machine supporting multiple file system types
* and/or a network can not include this define, regardless of
protection
* by the _POSIX_SOURCE and _POSIX_C_SOURCE flags.
*
* #define NAME_MAX 14
*/
I verified this on the following systems ('uname -a' output):
* SunOS hostname 5.10 Generic_142900-06 sun4u sparc SUNW,Sun-Fire-V890
* SunOS hostname 5.8 Generic_117000-05 sun4u sparc SUNW,Sun-Fire-480R
I could not build the original 3.1.14 under MinGW, so I didn't care of MinGW build at all. Do you really support this platform?
Yes, it really is supported, just like most other Unix-style platforms.
As far as I can see MinGW does not even support the fork() call [1], so I wonder how can smsd be built under MinGW. Have you really been able to compile it under MinGW?
[1] http://www.mingw.org/node/21
|
Mon May 09, 2011 08:23
|
unterwulf: Hi Keke,
The patchset is ready. Please find it at [1].
An autotools generated distribution is also available at [2]. It probably worth to be looked at firstly, as it doesn't require any additional tools to be installed.
Brief description of the new features:
- staging area installation support
- iconv/libiconv autodetection (can be explicitly enabled/disabled)
- inet socket availability autodetection (inet socket will be automatically disabled if the system doesn't support it)
- Cygwin autodetection (instead of the os_cygwin parameter)
- distribution autogeneration (make dist)
- more accurate handling of the installation prefix
- no need to edit Makefile, all parameters are configurable via the ./configure options.
Using this distribution I was able to build the software on Linux, Cygwin, SunOS 5.8, SunOS 5.9, OpenBSD and FreeBSD. I didn't tested any functionality of the software, only the building process itself (+compilation options etc).
BTW, support of Solaris seems to be broken in 3.1.12, so I had to fix it somehow to test the building process.
I could not build the original 3.1.14 under MinGW, so I didn't care of MinGW build at all. Do you really support this platform?
[1] https://github.com/unterwulf/smstools3-uw/commits/
[2] https://github.com/downloads/unterwulf/smstools3-uw/smstools3-3.1.14-uw.tar.gz
|
Mon May 02, 2011 09:47
|
unterwulf:
In some cases ICONV is not used, even when it's available, meaning that option is required for this. The same applies to INET_SOCKET. A definition USE_LINUX_PS_TRICK is removed in the next version, so it does not require any option.
These cases will be covered by ./configure --without-iconv --disable-inet-socket.
Previously os_cygwin was in the Makefile, but it was moved to the configuration. The same settings applies to MinGW too.
This still doesn't mean that it needs to be configurable in runtime. I can imagine only two situations when this parameter might need to be configurable in runtime:
1. It may need to be disabled when running under Cygwin.
2. The same binary can be used on several platforms that require different behavior.
Does any of two make sense in real life?
I am not familiar with MinGW, but my guess is that it still require that binary should be built for it as a target platform, and autoconf seems to be able to recognize mingw as well as cygwin.
Simple migration, like described for example at http://markuskimius.wikidot.com/programming:tut:autotools, was not enough.
If you can prepare the patch, I'm of course interested to see it.
OK.
Do you mean that Makefile should be compatible with both GNU make and OpenBSD's make?
Actually, no ;-) I mean that, despite the user had gmake, the building process didn't advice him to use it and he had to spent time to find it out himself.
OMG! I've just realized that I forgot to mention the main reason that forced me to modify smstools3 build process :-) Current implementation has no means to install the software into a staging area (see Staged-Installs for details), although this feature is very helpful for building packages.
|
Sun May 01, 2011 22:32
|
unterwulf: One more portability issue: [solved] Compile on OpenBSD 4.5
|
Sun May 01, 2011 22:13
|
unterwulf:
Currently I do now know about any portability issues, which could be automatically solved by Autotools (other than "-D SOLARIS").
Actually there are two more:
- Automake can detect whether iconv() is available and included in libc/installed as a separate library.
- The configuration parameter os_cygwin doesn't need to be configurable in runtime, it should be determined at compilation time.
In the past I quickly checked Autotools, but it seemed like a too big job to implement it.
It is a false impression :-) Migration to autotools is not a big deal. I can prepare the patch if you are interested in it.
|
Sun May 01, 2011 11:20
|
unterwulf: Hi,
I just want to know why smstools3 do not use some building system like autotools etc? I would be much easier for users to just perform a couple of well-known steps to have a best build for their system.
p.s. I have not found a forum for developers, so asking here. Let me know if there is some better place for such questions.
Vitaly
|
Page: 1
Time in this board is UTC.
|
|
|
 |
|
 |
|