Re: HEADS UP: utmp.h gone. All welcome utmpx.h.
On Wednesday 13 January 2010 20:42:54 Ed Schouten wrote: Hello everyone, I just made various commits to FreeBSD HEAD to remove our old user accounting database interface (see utmp(5)) and replace it by the POSIX standardized utmpx interface (see getutxent(3)). This means we just got rid of some annoyances that are as old as the FreeBSD project itself: - Hostnames were originally restricted to 16 bytes, which is way too short for your average hostname generated by your ISP, but also for IPv6 addresses, which are at most 32 + 7 = 39 characters. This is most welcome :-) - No support for login sessions not related to TTYs, like ppp(8), ftpd(8) sessions. - No support for multiple login sessions on one TTY, for example generated by login(1). I was not able to give us a smooth transition from utmp towards utmpx, simply because our utmp implementation offered almost no utility functions, which means all consumers modify the database files themselves. This means you should probably recompile any applications you're interested in that uses the user accounting database. I realize this may be quite uncomfortable, but we can't always win. [ This information is mainly for port maintainers: ] I've noticed there is some breakage in ports, but it shouldn't be too serious. I've seen cases where an application includes utmp.h, even though it doesn't use anything provided by that header. In other cases they used fields like UT_NAMESIZE to derive the maximum user name length supported by the system, which is clearly not what this definition was intended for. I've incremented __FreeBSD_version to 97 to identify the import of utmpx. In case a certain port breaks badly, let me know and I'm willing to take a look at it. Be sure to give it a try and report any issues. Thanks! From the commit logs I can tell it was a lot of work on something that many people wouldn't consider a very glamourous or spectacular piece of FreeBSD. So let me just say: Thanks! Cheers, Pieter de Goeje ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports/devel/protobuf: Segmentation fault in mmap in some applications
On Thursday 07 January 2010 10:02:36 O. Hartmann wrote:
On 01/07/10 01:41, Pieter de Goeje wrote:
On Wednesday 06 January 2010 14:14:28 O. Hartmann wrote:
Dear Sirs,
We use a software package for scientific imagery processing from USGS,
ISIS3 (http://isis.astrogeology.usgs.gov/). The most recent version is
3.1.21 and since this version, the software intensively uses
libprotobuf.so.
While we can use ISIS 3.1.20 very well under FreeBSD 8.0/amd64, it is
impossible to use the software with version no. 3.1.21, which seems to
have some issues wih libprotobuf.so. Every client out of this ISIS3
package crashes with a segmentation fault and as far as I can judge the
situation, there is a problem with libprotobuf.so, against which all
clients out of ISIS 3.1.21 are linked.
Perhaps the ISIS package was developed using a different (older?) version
of Google's protocol buffers. Compiling protobuf from source is quite
easy on FreeBSD. You can find the source here:
http://code.google.com/p/protobuf/downloads/list
I would start by trying version 2.1.0 and 2.2.0a.
I searched for help on the ISIS3-support forum and realised that some
Apple OS X guys have had similar problems, but those threads where
closed immediately or got relative senseless response.
In our case, we compile every necessary library and prerequisite
software package (mostly Qt4 libs) from ports. This works great with
some tweaks for FreeBSD in make/config.freebsd (which I derived from
some linux and/or OS X config files).
Now I'm floating like a dead man i the water. Below I provide q gdb
output of the qview-client (the same is with all other clients, like
photrim etc. for those familiar with the software package).
A backtrace ('bt' at the gdb prompt) might contain more useful
information.
Additionaly, I provide a truss-output, that stops at mmap issues.
Well, if someone could provide me with some advance debugging hints I
would appreaciate them. I'm pretty sure he problem is located within the
libprotobuf library or the way it is treated, but this is a guess of a
non-developer.
Thanks very much in advance.
Please reply also to this email address, since I'm not subscriber of the
list I post to.
Oliver
- Pieter
Hello Pieter,
ISIS3 utilises the very same revision of libprotobuf as FreeBSD has in
the ports repositorium (libprotobuf.so.4.0.0, aka protobuf-2.2.0). The
backtrace follows, it is a little bit lengthy ...
Ok, I can reproduce this locally. The cause is incorrect compiler flags.
Basically one must use `pkg-config --cflags protobuf` to get the correct
CFLAGS and `pkg-config --libs protobuf` for the correct libraries.
Most likely one or both of the following were missing during the
compilation/linking of ISIS: -D_THREAD_SAFE -pthread
Regards,
Pieter
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports/devel/protobuf: Segmentation fault in mmap in some applications
On Wednesday 06 January 2010 14:14:28 O. Hartmann wrote:
Dear Sirs,
We use a software package for scientific imagery processing from USGS,
ISIS3 (http://isis.astrogeology.usgs.gov/). The most recent version is
3.1.21 and since this version, the software intensively uses
libprotobuf.so.
While we can use ISIS 3.1.20 very well under FreeBSD 8.0/amd64, it is
impossible to use the software with version no. 3.1.21, which seems to
have some issues wih libprotobuf.so. Every client out of this ISIS3
package crashes with a segmentation fault and as far as I can judge the
situation, there is a problem with libprotobuf.so, against which all
clients out of ISIS 3.1.21 are linked.
Perhaps the ISIS package was developed using a different (older?) version of
Google's protocol buffers. Compiling protobuf from source is quite easy on
FreeBSD. You can find the source here:
http://code.google.com/p/protobuf/downloads/list
I would start by trying version 2.1.0 and 2.2.0a.
I searched for help on the ISIS3-support forum and realised that some
Apple OS X guys have had similar problems, but those threads where
closed immediately or got relative senseless response.
In our case, we compile every necessary library and prerequisite
software package (mostly Qt4 libs) from ports. This works great with
some tweaks for FreeBSD in make/config.freebsd (which I derived from
some linux and/or OS X config files).
Now I'm floating like a dead man i the water. Below I provide q gdb
output of the qview-client (the same is with all other clients, like
photrim etc. for those familiar with the software package).
A backtrace ('bt' at the gdb prompt) might contain more useful information.
Additionaly, I provide a truss-output, that stops at mmap issues.
Well, if someone could provide me with some advance debugging hints I
would appreaciate them. I'm pretty sure he problem is located within the
libprotobuf library or the way it is treated, but this is a guess of a
non-developer.
Thanks very much in advance.
Please reply also to this email address, since I'm not subscriber of the
list I post to.
Oliver
- Pieter
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
