| All Forums |
Register |
Login |
Search |
Subscriptions |
My Profile |
Inbox |
| Tool Warehouse |
FAQs |
Resources |
Help |
Member List |
Address Book |
Logout |
|
|
RE: FAQ for portability issues?
|
Logged in as: Guest |
| Users viewing this topic: none |
|
Login  |
|
|
 RE: FAQ for portability issues? - Oct. 3, '06, 8:55:09 PM
|
|
|
mkoeppe
Posts: 43
Joined: Dec. 8, '05,
Status: offline
|
While the strtoll/strtoull patch worked for my first program, I now recompiled bash, and there the patch breaks the build. The macro definitions aren't compatible with bash's configure, i.e. they are not recognized. And even worse, the bash version of strtoll can't be build because the strtoll macro is defined and therefore destroys the definition of bash's strtoll.
Maybe they should better be real functions in libport, just calling the *q funcs.
configure:11266: checking for strtoll
configure:11309: gcc -o conftest -g -O2 -D_ALL_SOURCE -I/usr/local/include -I/usr/local/ssl/include -L/usr/local/lib -L/usr/local/ssl/lib conftest.c >&5
/tmp/ccW0jZQf.o(.text+0x1a): In function `main':
/srv/bash/bash-3.1/build-bash/configure:11299: undefined reference to `_strtoll'
collect2: ld returned 1 exit status
configure:11312: $? = 1
configure: failed program was:
#line 11271 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
which can conflict with char strtoll (); below. */
#include <assert.h>
/* Override any gcc2 internal prototype to avoid an error. */
#ifdef __cplusplus
extern "C"
#endif
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char strtoll ();
char (*f) ();
#ifdef F77_DUMMY_MAIN
# ifdef __cplusplus
extern "C"
# endif
int F77_DUMMY_MAIN() { return 1; }
#endif
int
main ()
{
/* The GNU C library defines this for functions which it implements
to always fail with ENOSYS. Some functions are actually named
something starting with __ and the normal name is an alias. */
#if defined (__stub_strtoll) || defined (__stub___strtoll)
choke me
#else
f = strtoll;
#endif
;
return 0;
}
configure:11328: result: no
|
|
|
|
|
RE: FAQ for portability issues? - Oct. 4, '06, 7:44:46 AM
|
|
|
mkoeppe
Posts: 43
Joined: Dec. 8, '05,
Status: offline
|
Hi Rodney,
I now modified the strtoll patch. I removed the preprocessor function definitions from stdlib.h and just wrote:
#define strtoll strtoq
#define strtoull strtouq
That way it works for me with bash, which checks for strtoll, and with dash, which assumes strtoll to be there. bash's configure doesn't recognize having strtoll, but building the bash supplied version of strtoll doesn't break with these #defines.
Nevertheless an own function definition in libport may be cleaner, as formally strtoll returns long long and strtoq returns quad_t.
Tried the following, too. Unfortunately the configure test doesn't recognize this and the bash build fails again (dash works, however):
static inline quad_t
strtoll(const char *a, char **b, int c)
{
return strtoq(a, b, c);
}
static inline quad_t
strtoull(const char *a, char **b, int c)
{
return strtouq(a, b, c);
}
< Message edited by mkoeppe -- Oct. 4, '06, 7:55:03 AM >
|
|
|
|
|
RE: FAQ for portability issues? - Oct. 4, '06, 1:04:14 PM
|
|
|
Rodney
Posts: 3695
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
Just as an aside... for building bash I've not used changes to header files.
This is an easy enough add to libport.
|
|
|
|
|
RE: FAQ for portability issues? - Oct. 5, '06, 8:19:33 AM
|
|
|
mkoeppe
Posts: 43
Joined: Dec. 8, '05,
Status: offline
|
1.) I had the following problem with my bash: When run as login shell, it didn't work, but from within ksh it was ok, i.e. probably the same as here: http://www.interopsystems.com/tools/fb.aspx?m=10123 My static version of bash worked, however. I then added /usr/local/lib to the system environment variable LD_LIBRARY_PATH, so that it is set before /etc/profile is processed, and now my bash works as login shell as well. For resolving those issues more easily my question is:
Rodney, is there a list somewhere saying which compile options you used on each /Tools package, i.e. gcc/c89, -L/usr/local/lib, -lport, -D_USE_LIBPORT etc.?
2.) Another issue occurs with my bash, though. It doesn't matter if login shell or not. When starting a shell script, I get several of:
shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
With /Tools bash, this doesn't occur. I tried my bash with -lport and -D_USE_LIBPORT as well as without -lport, but in both cases with libs from /usr/local/lib which configure found itself, e.g. libintl. Having bash with -D_USE_LIBPORT has 1 "advantage": \$ in PS1 resolves to # instead of $ for Administrator. Don't know if there are others.
3.) And still another thing, which I'm trying to find out:
$ /lib/ld.so.1 --list /usr/local/bin/sed.bak
libc.so.3.5 => /usr/lib/libc.so.3.5 (0x77d80000)
$ /lib/ld.so.1 --list /usr/local/bin/sed
/usr/local/bin/sed: error in loading shared libraries
/usr/local/bin/sed: system cannot load image
$ /lib/ld.so.1 --list /usr/local/bin/bash
/usr/local/bin/bash: error in loading shared libraries
/usr/local/bin/bash: system cannot load image
Both versions of sed I made myself with system gcc, and both versions work, only the above is different. Unfortunately I can't remember the build options for the working one, in sense of above. /usr/local/bin/bash is from /Tools.
|
|
|
|
|
RE: FAQ for portability issues? - Oct. 5, '06, 11:56:56 AM
|
|
|
Rodney
Posts: 3695
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
1) For nearly all of the packages libport was not used. And certainly not for bach.
Bash was built using gcc. Basically anthing that uses a configure script will use
gcc because those that wrote the script add all those funky options that only gcc
knows about. There's a "README.Interix" file with comments about each port with the sources. The
comments relate back to Interix 3.0 and the bash 2.x version, but not much has changed. There
was also Reid Madsen's terminal change, but that's in the source already.
2) Right, that's a change in the source as well. The code was expecting a non-standard behavior.
So there's an #ifdef __INTERIX for that. The "#" versus "$" prompt is a uid handling thing.
You may eventually notice that you need to "-DUSE_POSIX_GLOB_LIBRARY".
3) Use "objdump -p <filename>" instead.
|
|
|
|
|
RE: FAQ for portability issues? - Oct. 6, '06, 4:42:01 PM
|
|
|
mkoeppe
Posts: 43
Joined: Dec. 8, '05,
Status: offline
|
I now have extracted the patches applied to bash in order to apply them to bash-3.1. Thank you for the hint, Rodney. I found that getcwd patch there, and that upstream configure even checks for the enhanced getcwd with malloc, but I didn't find a usage of that check result. :-(
But instead of (or maybe besides) patching bash, why not include the malloc enhanced getcwd into libport? There certainly are other apps (e.g. dash) that are depending on the malloc enhancement and call getcwd(0,0), which I now found out. Adapted, but never compiled, from bash's patched source:
char *_port_getcwd(char *buf, size_t size)
{
if (buf) {
return getcwd(buf, size);
}
else {
size_t s = size ? size : PATH_MAX+1;
char* path = malloc(s);
if (! path) return NULL;
char* res = getcwd(path, s);
if (! res) {
free(path);
return NULL;
}
if (! size) {
res = realloc(path, strlen(path)+1);
}
/* if realloc fails, return path */
return res ? res : path;
}
}
|
|
|
|
|
RE: FAQ for portability issues? - Oct. 6, '06, 4:54:07 PM
|
|
|
Rodney
Posts: 3695
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
Thanksgiving here. So I'll get to this next week now.
|
|
|
|
|
RE: FAQ for portability issues? - Oct. 8, '06, 4:03:00 PM
|
|
|
mkoeppe
Posts: 43
Joined: Dec. 8, '05,
Status: offline
|
Hi Rodney,
I found that interix's implicit socklen_t type (int) collides with what some programs expect: an unsigned type socklen_t. I suggest modifying libport's sys/socket.h so that socklen_t is something unsigned, I found size_t at some place.
libport: sys/socket.h:
/* hide original declarations */
#define accept accept_interix
#define bind bind_interix
#define connect connect_interix
#define getpeername getpeername_interix
#define getsockname getsockname_interix
#define getsockopt getsockopt_interix
#define recvfrom recvfrom_interix
#define sendto sendto_interix
#define setsockopt setsockopt_interix
#include "/usr/include/sys/socket.h"
/* redeclare with socklen_t */
#undef accept
#undef bind
#undef connect
#undef getpeername
#undef getsockname
#undef getsockopt
#undef recvfrom
#undef sendto
#undef setsockopt
#ifdef socklen_t
#undef socklen_t
#endif
typedef size_t socklen_t;
#ifdef __cplusplus
extern "C" {
#endif
int __cdecl accept (int, struct sockaddr *, socklen_t *);
int __cdecl bind (int, const struct sockaddr *, socklen_t);
int __cdecl connect (int, const struct sockaddr *, socklen_t);
int __cdecl getpeername (int, struct sockaddr *, socklen_t *);
int __cdecl getsockname (int, struct sockaddr *, socklen_t *);
int __cdecl getsockopt (int, int, int, void *, socklen_t *);
ssize_t __cdecl recvfrom (int, void *, size_t, int, struct sockaddr *, socklen_t *);
ssize_t __cdecl sendto (int, const void *, size_t, int, const struct sockaddr *, socklen_t);
int __cdecl setsockopt (int, int, int, const void *, socklen_t);
#ifdef __cplusplus
}
#endif
|
|
|
|
|
RE: FAQ for portability issues? - Oct. 8, '06, 5:58:43 PM
|
|
|
mkoeppe
Posts: 43
Joined: Dec. 8, '05,
Status: offline
|
Another issue occured: /usr/include/langinfo.h is not C++ compatible. I suggest adding to libport:
#ifndef LANGINFO_H_LOCAL
#define LANGINFO_H_LOCAL
#ifdef __cplusplus
extern "C" {
#endif
#include "/usr/include/langinfo.h"
#ifdef __cplusplus
}
#endif
#endif /* LANGINFO_H_LOCAL */
Maybe one could change the #include to
#include "../langinfo.h"
This seems to work with gcc. Don't know about c89, but when reading the VC2005 docs, it seems possible there, too, so maybe this can simplify libport.
|
|
|
|
|
RE: FAQ for portability issues? - Oct. 11, '06, 8:07:45 PM
|
|
|
mkoeppe
Posts: 43
Joined: Dec. 8, '05,
Status: offline
|
Hi Rodney,
1.) an addition to libport, netinet/in.h
#ifndef _NETINET_IN_H_LOCAL
#define _NETINET_IN_H_LOCAL
#include "/usr/include/netinet/in.h"
/* Address to loopback in software to local host. */
#ifndef INADDR_LOOPBACK
# define INADDR_LOOPBACK ((in_addr_t) 0x7f000001) /* Inet 127.0.0.1. */
#endif
#endif /* _NETINET_IN_H_LOCAL */
2.) Where is or is there a getnameinfo(3)?
|
|
|
|
|
RE: FAQ for portability issues? - Oct. 11, '06, 10:24:44 PM
|
|
|
Rodney
Posts: 3695
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
You want to install BIND for the getnameinfo() API.
The header files end up under /usr/local/include/bind;
the API in libbind.a in /usr/local/lib.
|
|
|
|
|
RE: FAQ for portability issues? - Oct. 15, '06, 6:41:11 PM
|
|
|
mkoeppe
Posts: 43
Joined: Dec. 8, '05,
Status: offline
|
Hi Rodney,
1. could you put sysexits.h into libport?
2. while trying to build a wide-char version of libncurses, I got a linker error because of missing
- wmemchr
- wcsrtombs
- wcrtomb
- mbrtowc
- wmemcpy
|
|
|
|
 New Messages |
 No New Messages |
 Hot Topic w/ New Messages |
 Hot Topic w/o New Messages |
|
 Locked w/ New Messages |
 Locked w/o New Messages |
|
 Post New Thread
Reply to Message
Post New Poll
Submit Vote
Delete My Own Post
Delete My Own Thread
Rate Posts |
|
|
|
Printable Version
