Re: Booting from FAT(32)
On Sun, 14 Jun 2009, Daniel O'Connor wrote:
> > I've been meaning to trial it out actually. It sure would be
> > interesting to boot a kernel/mfs off of a DOS bootable FAT USB.
>
> I think you can do it if you makefs /boot and feed it to syslinux
> using memdisk (I plan on trying this today).
I used Luigi's iso2flash.sh script (the guts thereof) and it worked fine, ie..
mkdir /tmp/boot
cp -r /boot /tmp/boot
[ fixup /tmp/boot/boot how you like ]
makefs -t ffs -o bsize=4096 -o fsize=512 -f 50 /tmp/boot.img /tmp/boot
bsdlabel -Bw -f /tmp/boot.img auto
bsdlabel -f /tmp/boot.img | sed -e '/ c:/{p;s/c:/a:/;}' | bsdlabel -R -f
/tmp/boot.img /dev/stdin
gzip /tmp/boot.img
(Using -B obviated the need for the dd magic in the original script)
Copy /tmp/boot.img.gz to the USB stick and then you can use a syslinux conf
like..
label FreeBSD
kernel memdisk
append initrd=boot.img.gz
I got the kernel to mount root off the FAT32 partition although you need to
make sure /dev exists and all the binaries & libs it wants are present.
(eg mkdir /mnt/dev ; cp -r /bin /sbin /lib /libexec /mnt)
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
signature.asc
Description: This is a digitally signed message part.
Re: Booting from FAT(32)
On Sun, 14 Jun 2009, Adrian Chadd wrote: > I believe there's some NetBSD FAT32 aware loader. Dianora stumbled > across it when I was talking about this very thing earlier. I thought the FreeBSD loader spoke FAT32 already, although now I go and have a proper look I see otherwise :( > I've been meaning to trial it out actually. It sure would be > interesting to boot a kernel/mfs off of a DOS bootable FAT USB. I think you can do it if you makefs /boot and feed it to syslinux using memdisk (I plan on trying this today). I was thinking the loader had FAT support though so I could just get Syslinux to load the loader then it would do the rest. Although heck how hard can read only FAT support be to write? :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: Maybe confused about AMD64 / i386 compatibility
On 2009-Jun-13 15:55:29 -0500, Joe Greco wrote: >Adding a SIL3112A gives us the SATA. These are known to cause data corruption (check the archives). I wouldn't trust anything that has passed through a SIL chip without independent validation. -- Peter Jeremy pgpMf1MOQkbWz.pgp Description: PGP signature
Re: Maybe confused about AMD64 / i386 compatibility
> On 2009-Jun-13 15:55:29 -0500, Joe Greco wrote: > >Adding a SIL3112A gives us the SATA. > > These are known to cause data corruption (check the archives). I > wouldn't trust anything that has passed through a SIL chip without > independent validation. I already said it had been validated. gunzip|restore tvf was happy with the entire thing. A FreeBSD 6.1R/amd64 box is currently happily RESTORING the SIL-written gzip'ed file using a USB-to-SATA adaptor, TOO, so all evidence is that the on-disk file data is sane. I checked for general data corruption at the device level with md5 and posted a brief summary of those results; the results are that everything appears to be reading the disk blocks sanely. That was why I posted such a long summary of what had been done; I felt certain someone would try to claim dodgy hardware. The SIL does seem to spit off lots of spurious interrupts, and does not work at all with non-native SATA drives; being a backup system, I had already stress tested various combinations of things, and I'm aware of the various PC hardware deficiencies. So, let me re-summarize and simplify the issue to clarify: I have a large (~400GB) file on a large (~1.5TB) filesystem created on 7.2R-i386. 7.2R-i386 reads the file correctly (via SIL or via USB-to-SATA). 6.1R-amd64 reads the file correctly (via USB-to-SATA). 7.1R-amd64 does NOT read the file correctly (via USB-to-SATA). In all of the above cases, the underlying hardware and device drivers appear to be returning the same data, as evidenced by dd |md5 of random portions of the disk. In other words, the SIL is not in the equation. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Porting problem with gnu configure (c++ -V)
On Sat, Jun 13, 2009 at 10:23:50PM +0200, Dag-Erling Sm??rgrav wrote: > Alex de Kruijff writes: > > Andrey Simonenko writes: > > > It's better to see your version for configure.ac, since without its > > > content it is hard to say something. > > Oke here it is: > > This configure.ac can not possibly have produced the configure.log you > posted earlier. Can you please show us the *real* configure.ac and / or > configure.log? > > DES > -- > Dag-Erling Sm??rgrav - d...@des.no The file is processed by sed, but the only difference is: -AC_INIT(FULL-PACKAGE-NAME, VERSION, BUG-REPORT-ADDRESS) +AC_INIT(SameSame, 1.3, sames...@akruijff.dds.nl) There is no configure.log. -- Alex Please copy the original recipients, otherwise I may not read your reply. http://samesame.kruijff.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Maybe confused about AMD64 / i386 compatibility
Background (most probably not necessary): We use rsync snapshots and cheap IDE disks as part of our backup strategy. Recently, a backup server started getting near full, and with 1.5TB disks being what they are, we shot to replace a 750GB IDE with a 1.5TB SATA. The backup server was upgraded to FreeBSD 7.2R/i386, it sports a 4GB flash which leaves two drive bays in the Intel ISP1100 chassis available. Adding a SIL3112A gives us the SATA. Good to go. Create 1.5TB filesys, and copy the old 750GB to it. Option 1, using dd followed by growfs, doesn't work. Groan. growfs bombs out with a negative integer in some array, and it isn't clear to me what is happening. So let's do the old slow but reliable dump/restore. Except that a dump/restore of the filesystem, which is full of hardlinks, causes massive resource consumption and eventual exhaustion. Okay, fine. Option 2, dump with gzip -1 to a file on the new drive (it'll have enough space to restore in a separate step). This works great. Verify file integrity (~400GB). Also just fine. Restore. Watch restore grow to near 3GB and then bail. Okay, obviously an i386 architecture won't handle this restore. So, think, aha, I'll go and put it on a FreeBSD 7.1R/amd64 Opteron box with 8GB that is idle at the moment. -->> And here's where it all goes wonky. Using a USB-to-SATA adapter, I plug in the drive to the amd64. It sees it. I mount it. All looks fine. Good! # mount /dev/da1s1d /mnt # df Filesystem 1K-blocks Used Avail Capacity Mounted on [...] /dev/da1s1d 1419039310 432472500 87304366633%/mnt Now I try a restore. So I do "gunzip < ad3s1e.dmp2 | restore rvf -" ... and gzip claims the data isn't compressed. # gunzip < ad3s1e.dmp2 | restore rvf - gunzip: stdin: not in gzip format Verify tape and initialize maps End-of-tape encountered Tape is not a dump tape Look at the data, looks generally compressed. But file(1) sees it as "data", not gzip data. So, scratch head, wonder if it might be some odd gzip incompatibility, get latest GNU gzip, still no go. Rather annoyed, I think, "but I know I verified this was a good file" - so I take the disk back to the i386, put it in on the SATA controller, and it works fine. So suddenly I think the USB-to-SATA is garbage and is corrupting the data. I md5 the first portions of the file, and go back, put the disk on the amd64 with the USB-to-SATA. # dd if=ad3s1e.dmp2 bs=2048 count=1 | md5 Returns f86ea62b2c77c58691001371c283c7a0 on i386, 43ca53ad03650bc8c8fd1279ce19a675 on amd64. !!! This seems really odd. So just to be sure, I go back to the i386 box, this time with the USB-to-SATA... and it returns the correct answer. Double "!" Now I finally get smart and try working with the raw disk device. # dd if=/dev/da1s1 bs=2048 count=1024 | md5 1024+0 records in 1024+0 records out 2097152 bytes transferred in 7.189189 secs (291709 bytes/sec) 504efcdd93164c496c07603ba9b3774c In all cases: 7.1amd64/USB: 504efcdd93164c496c07603ba9b3774c 7.2i386/SATA: 504efcdd93164c496c07603ba9b3774c 7.1amd64/USB: 504efcdd93164c496c07603ba9b3774c So the underlying hardware and driver support "seems" to be fine. And now this brings me to my question. In my experience, FreeBSD filesystems are portable across i386-amd64. Are there circumstances where this isn't the case? I'm happy to concede that the filesystem in question is rather largish (1.5TB) and probably stresses things a little bit. # ls -al total 432471268 drwxr-xr-x5 root wheel 512 Jun 13 11:07 . drwxr-xr-x 24 root wheel 512 Feb 18 09:18 .. drwxrwxr-x2 root operator 512 Jun 5 08:20 .snap -rw-r--r--1 root wheel 434044319653 Jun 10 19:25 ad3s1e.dmp2 -rw-r--r--1 root wheel 33 Jun 13 11:07 c1 -rw-r--r--1 root wheel 33 Jun 13 11:07 c1024 -rw-r--r--1 root wheel 33 Jun 13 11:07 c256 -rw-r--r--1 root wheel 33 Jun 13 11:07 c4 -rw-r--r--1 root wheel 80 Jun 13 10:43 logfile drwx-- 293 root wheel18432 Jun 8 04:25 lost+found -rw-rw-rw-1 root wheel 8589934592 Jun 8 00:33 swapfile drwxrwxrwx9 root wheel 512 Jun 8 14:14 x Oh, and just to add some pain and agony to the puzzle ... it all seems to work fine on 6.1-RELEASE/amd64 ... and 7.0-RELEASE/amd64. But on a different machine. Which is where I'm doing my extraction. So I'm not sure what to make of this. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. ___
Re: sysinstall, GJOURNAL and ZFS
Which Wiki do you want me to contribute this to? http://wiki.freebsd.org/FreeBSD/BSDInstaller2009 or http://wiki.bsdinstaller.org/wikka.php?wakka=BSDInstaller ? Whichever it is, I am not that experienced with editing Wikis, so perhaps you could create the needed sections/subsections for usability issues and I would look into filling my thoughts into them when I have some time? Sincerely, - Dan Naumov On Sat, Jun 13, 2009 at 10:47 PM, Scott Ullrich wrote: > Really appreciate all of the advice but I am hoping that it does not > get lost. Do you mind helping me update the Wiki with your > suggestions? Maybe add a usability improvements section. If not I > can get it updated later this weekend. > > Also I am working on getting 7-STABLE snapshots together and embedded > images suitable for compact flash cards ala DD/physdiskwrite.exe. > > Scott > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Porting problem with gnu configure (c++ -V)
Alex de Kruijff writes: > Andrey Simonenko writes: > > It's better to see your version for configure.ac, since without its > > content it is hard to say something. > Oke here it is: This configure.ac can not possibly have produced the configure.log you posted earlier. Can you please show us the *real* configure.ac and / or configure.log? DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: sysinstall, GJOURNAL and ZFS
On Sat, Jun 13, 2009 at 3:56 PM, Dan Naumov wrote: > Which Wiki do you want me to contribute this to? > http://wiki.freebsd.org/FreeBSD/BSDInstaller2009 or > http://wiki.bsdinstaller.org/wikka.php?wakka=BSDInstaller ? Whichever > it is, I am not that experienced with editing Wikis, so perhaps you > could create the needed sections/subsections for usability issues and > I would look into filling my thoughts into them when I have some time? I just added a section to http://wiki.freebsd.org/FreeBSD/BSDInstaller2009 .. It's quite easy to work the wiki. Thanks for the suggestions and testing the Installer! Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: sysinstall, GJOURNAL and ZFS
On Fri, Jun 12, 2009 at 6:07 PM, Dan Naumov wrote: > As promised, I took a go at this new BSDInstaller, I wrote down some > of my thoughts. Since I don't know if this is the kind of feedback you > are looking for, here is just a part of it. As you can probably guess > from it, I deal with usability issues in software applications a lot, > hence my point of view, but obviously I can find my way around a UNIX > without much issues. Thanks!! > > FreeBSD-20090608-1522-8.0-CURRENT image was used: > = > Initial BOOT: > The boot goes as planned, but the user is dropped off to a login > prompt. There is no direct indication for the user regarding how to > proceed. Adding a note just before the login prompt saying something > like "login as "root" with an empty password" would be nice. Again, as > soon the user does log on, there is no indication as to how to launch > the actual installer. This, as well as the previous problem could be > solved by presenting the user with a simple menu screen, like this: > > Welcome to FreeBSD, choose your option: > 1: Launch the FreeBSD installer > 2: Drop to an emergency rescue shell That is one part that I have not touched on as of yet. DragonFly has a "installer" account that launches the BSDI but I am not too sure if thats how we should visit this or not? > This would eleminate the actual need to log in as well, we could just > autologin as root for both options. > > Initial options in the actual installer: > option: the names in a long list don't actually > tell the user anything regarding how does any of the fonts look. Would > it be possible to have a small sample preview next to each presented > font option? > option: again, the screen map options do not > really explain the user what he should be choosing. A short > description of every option is needed at the very least. > option: ditto, same thing. Good ideas. Any chance you can add them to the wiki? > Another approach to this altogether could be a serious of questions > like: "What country do you live in? What language is your keyboard?" > providing multiple options for an answer for each question. After a > series of questions, the installer could just automatically pick up > most sane defaults based on the answers given by the user and finally > ask "Does the fonts on the screen look alright to you? Try typing in > here, do the expect characters appear as they should?" and if the user > is unsatisfied, he can be dropped to the kinds of a big selection list > which is used by the installer right now. > > short description, a lot of the kernel module names are cryptic and a > new user cannot be reasonably expected to evaluate and make an > informed decision regarding what he does want and what he doesn't > based on a simple file list of the modules. Also a good idea and should be relatively easy if we can pull the short description dynamically somehow vs. hard coding it? > screen: The screen states that in order to do a > manual installation " login as root, and follow the instructions > given in the file /README". There is no indication regarding how the > user is supposed to open the README file, at least ONE sane option > should be suggested (for example: login as root and type "vi README" > at the command prompt to read the instructions regarding installing > FreeBSD manually. This is leftover and also needs to be addressed. So far I have focused on getting the BSDI ported to FreeBSD and to remove the "pfSense'sms" that where present. Really appreciate all of the advice but I am hoping that it does not get lost. Do you mind helping me update the Wiki with your suggestions? Maybe add a usability improvements section. If not I can get it updated later this weekend. Also I am working on getting 7-STABLE snapshots together and embedded images suitable for compact flash cards ala DD/physdiskwrite.exe. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: top shows that multithreaded program uses 19623.14% CPU
In the last episode (Jun 13), Yuri said: > I ran then program with 1500 threads and in top it looked the this: > > PID USERNAMETHR PRI NICE SIZERES STATE C TIMECPU COMMAND > 20382 yuri 1500 990 641M 462M umtxn 0 0:00 19623.14% > quicksort > > > Where can I read how CPU column is calculated? > > Some time ago I saw another weird fenomenon when CPU column: 5% CPU load > for the pocess that just cycles in CPU. Top doesn't seem to show the right %CPU at all for threaded apps unless you hit H to view each thread individually. Then you get accurate numbers (but you have to manually sum up the threads usage if you want to see the total %CPU for an entire process). -- Dan Nelson dnel...@allantgroup.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: pthread_mutexattr_getprioceiling error?
On Sat, 13 Jun 2009, Михаил Кипа wrote:
Next little program:
#include
#include
int main()
{
pthread_mutexattr_t t;
if (pthread_mutexattr_init(&t)) return 1;
int i;
std::cout << pthread_mutexattr_getprioceiling(&t, &i) << std::endl;
}
always print 22. It means that pthread_mutexattr_getprioceiling always
fails with EINVAL. Under Linux this example works fine, but under
FreeBSD 7.2 it does`n work. Is it a bug in FreeBSD thread library or
it ai my misunderstanding?
Well, you can't get the priority ceiling of a _mutex_ if
it the protocol is PTHREAD_PRIO_NONE. See the POSIX spec,
excerpt here (pthread_mutex_getprioceiling):
These functions shall fail if:
[EINVAL]
The protocol attribute of mutex is PTHREAD_PRIO_NONE.
POSIX makes no mention of this for operations on a mutex attribute,
but I have no idea why it wouldn't have the same error returned
under similar conditions.
Why would you want to get the priority ceiling of a mutex
attribute that is not PTHREAD_PRIO_PROTECT? What value
could the implementation return in this case anyway, it
really doesn't make sense?
--
DE___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Booting from FAT(32)
I believe there's some NetBSD FAT32 aware loader. Dianora stumbled across it when I was talking about this very thing earlier. I've been meaning to trial it out actually. It sure would be interesting to boot a kernel/mfs off of a DOS bootable FAT USB. Adrian 2009/6/13 Daniel O'Connor : > Does anyone have a recipe for such a thing? > I currently have a split FAT32/UFS install USB stick but I'd like to get > it to just FAT32 if possible.. > > I think I can do it once I can run the loader - I can then load an MFS > and use UZIP for the FSs and so on.. > > I have been playing with Syslinux but it doesn't like > loading /boot/loader as a linux kernel and I'm not sure which format to > try. > > I think I can get it to work using the memdisk syslinux thing but that > seems like a kludge.. > > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: pthread_mutexattr_getprioceiling error?
On Sat, Jun 13, 2009 at 05:59:12PM +0400, Михаил Кипа wrote:
> Next little program:
> #include
> #include
> int main()
> {
> pthread_mutexattr_t t;
> if (pthread_mutexattr_init(&t)) return 1;
> int i;
> std::cout << pthread_mutexattr_getprioceiling(&t, &i) << std::endl;
> }
> always print 22. It means that pthread_mutexattr_getprioceiling always
> fails with EINVAL. Under Linux this example works fine, but under
> FreeBSD 7.2 it does`n work. Is it a bug in FreeBSD thread library or
> it ai my misunderstanding?
The priority ceiling is only meaningful with the PTHREAD_PRIO_PROTECT
protocol (pthread_mutexattr_setprotocol()). The FreeBSD threads library
returns EINVAL if you try to get/set the priority ceiling with another
protocol.
--
Jilles Tjoelker
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Booting from FAT(32)
Does anyone have a recipe for such a thing? I currently have a split FAT32/UFS install USB stick but I'd like to get it to just FAT32 if possible.. I think I can do it once I can run the loader - I can then load an MFS and use UZIP for the FSs and so on.. I have been playing with Syslinux but it doesn't like loading /boot/loader as a linux kernel and I'm not sure which format to try. I think I can get it to work using the memdisk syslinux thing but that seems like a kludge.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
pthread_mutexattr_getprioceiling error?
Next little program:
#include
#include
int main()
{
pthread_mutexattr_t t;
if (pthread_mutexattr_init(&t)) return 1;
int i;
std::cout << pthread_mutexattr_getprioceiling(&t, &i) << std::endl;
}
always print 22. It means that pthread_mutexattr_getprioceiling always fails
with EINVAL. Under Linux this example works fine, but under FreeBSD 7.2 it
does`n work. Is it a bug in FreeBSD thread library or it ai my misunderstanding?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Porting problem with gnu configure (c++ -V)
On Sat, Jun 13, 2009 at 03:01:17PM +0300, Andrey Simonenko wrote: > Hello, > > On Sat, Jun 13, 2009 at 01:06:18PM +0200, Alex de Kruijff wrote: > > I'm converting my port samesame to use gnu configue, but came a cross a > > problem that is beond me. I'm able to run aclocal, autoconf, autoheader > > and automake --add-missing -c. I've read the docs for autoconf and > > automake and search the web, but dont know how to solve elegantly. I > > would proberbly be able to hack configure, but prevere to edit only the > > source files. Do other porters with more experiance have any tips for > > me? > > It's better to see your version for configure.ac, since without its > content it is hard to say something. Oke here it is: # Process this file with autoconf to produce a configure script. AC_PREREQ(2.61) AC_INIT(FULL-PACKAGE-NAME, VERSION, BUG-REPORT-ADDRESS) AM_INIT_AUTOMAKE AC_CONFIG_SRCDIR([configure.h]) AC_CONFIG_HEADER([config.h]) # Checks for programs. AC_PROG_CXX #AC_PROG_CC AC_PROG_INSTALL AC_PROG_LN_S # Checks for libraries. # Checks for header files. AC_HEADER_STDC AC_CHECK_HEADERS([fcntl.h limits.h locale.h stddef.h stdint.h stdlib.h string.h unistd.h]) # Checks for typedefs, structures, and compiler characteristics. AC_C_CONST AC_C_INLINE AC_TYPE_OFF_T AC_TYPE_PID_T AC_TYPE_SIZE_T AC_HEADER_TIME # Checks for library functions. AC_FUNC_LSTAT AC_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK AC_FUNC_MALLOC AC_FUNC_MEMCMP AC_FUNC_MMAP AC_TYPE_SIGNAL AC_FUNC_STAT AC_CHECK_FUNCS([gettimeofday localeconv memset mkdir munmap rmdir strstr]) AC_CONFIG_FILES([Makefile]) AC_OUTPUT -- Alex Please copy the original recipients, otherwise I may not read your reply. http://samesame.kruijff.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Porting problem with gnu configure (c++ -V)
I'm converting my port samesame to use gnu configue, but came a cross a
problem that is beond me. I'm able to run aclocal, autoconf, autoheader
and automake --add-missing -c. I've read the docs for autoconf and
automake and search the web, but dont know how to solve elegantly. I
would proberbly be able to hack configure, but prevere to edit only the
source files. Do other porters with more experiance have any tips for
me?
The machine runs on FreeBSD 6.1-p20.
When building the port I get this message:
===> Configuring for samesame-1.3
configure: WARNING: you should use --build, --host, --target
checking for a BSD-compatible install... /usr/bin/install -c -o root -g
wheel
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... no
checking for nawk... nawk
checking whether make sets $(MAKE)... yes
checking for C++ compiler default output file name...
configure: error: C++ compiler cannot create executables
See `config.log' for more details.
===> Script "configure" failed unexpectedly.
- Config.log show the following:
configure:2329: c++ --version >&5
c++ (GCC) 3.4.4 [FreeBSD] 20050518
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
configure:2332: $? = 0
configure:2339: c++ -v >&5
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.4.4 [FreeBSD] 20050518
configure:2342: $? = 0
configure:2349: c++ -V >&5 < --- ---
c++: `-V' option must have argument
configure:2352: $? = 1
configure:2375: checking for C++ compiler default output file name
configure:2402: c++ -O2 -fno-strict-aliasing -pipe -DWITH_DISK_STORAGE
-DWITH_MM
AP -D'TEMP_STORAGE_DIR="/tmp"' -DPATH_INIT=256
-DSTATIC_CACHE_CAPACITY=8192 co
nftest.cpp >&5
:4:1: macro names must be identifiers
configure:2405: $? = 1
configure:2443: result:
configure: failed program was:
| /* confdefs.h. */ /
| #define PACKAGE_NAME "SameSame"
| #define PACKAGE_TARNAME "samesame"
| #define PACKAGE_VERSION "1.3"
| #define PACKAGE_STRING "SameSame 1.3"
| #define PACKAGE_BUGREPORT "sames...@akruijff.dds.nl"
| #define PACKAGE "samesame"
| #define VERSION "1.3"
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:2449: error: C++ compiler cannot create executables
See `config.log' for more details.
--
Alex
Please copy the original recipients, otherwise I may not read your reply.
http://samesame.kruijff.org/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: GNAT on FreeBSD amd64
On 2009-06-13 01:42:05, Михаил Кипа wrote: > I need gnat on FreeBSD 7.2 amd64, but in ports it is only for i386 :(. I have > tired to compile cross compiler under linux, and now I can compile my ada > programs under linux for FreeBSD, but I can`t compile native amd64 FreeBSD > gcc. > Can anybody help me with GNAT under amd64 FreeBSD? Hello. A port is on the way, I'm working on it. I've also spoken to Karel Miklav, the maintainer of the current lang/gnat-gcc ports with regards to updating them to be amd64 compatible too. I'm currently blocked waiting for a replacement for an RMA'd hard disk but development will resume the minute it turns up. Nice to see some interest in this port! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
top shows that multithreaded program uses 19623.14% CPU
I ran then program with 1500 threads and in top it looked the this: PID USERNAMETHR PRI NICE SIZERES STATE C TIMECPU COMMAND 20382 yuri 1500 990 641M 462M umtxn 0 0:00 19623.14% quicksort Where can I read how CPU column is calculated? Some time ago I saw another weird fenomenon when CPU column: 5% CPU load for the pocess that just cycles in CPU. Yuri 7.2-STABLE, i7-920 (4 CPUs) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
