Mail Archives: djgpp/2011/12/27/22:45:09
Hi,
On Dec 27, 7:55 pm, jimm <jmich DOT DOT DOT AT yahoo DOT com> wrote:
>
> > > Wextra -v -save-temps -s -Map=pthreads.map -oa.exe pthreads.cpp
>
> > Isn't GNU ld.exe a bit picky about link order? You may want to keep -
> > lpth to the end, though that probably won't solve your problem here.
>
> I thought -lpth as a switch should be before the files to be included
> in compilation since it is a switch. I thought that if it was at the
> end it would be interpreted as a filename.
It is interpreted as a filename because it's a library you need to
link with. It's not part of GCC proper. You could also hardcode it via
"/dev/env/DJDIR/lib/libpth.a" instead, which would also work but is
longer (as DJ already mentioned). Though I suggest you use FSU
pthreads instead.
> > > In file included from pthreads.cpp:1:0:
> > > c:/djc462~1/include/pthread.h:113:53: fatal error: sys/socket.h: No
> > > such file or directory (ENOENT)
> > > compilation terminated.
>
> > You need libsocket (/current/v2tk/ls080*.zip) or Watt-32. I'm not sure
> > the former even fully works (anymore, if ever), so I would suggest
> > Watt-32 from http://home.broadpark.no/~gvanem/
>
> I don't see how threads and sockets even related. seems totally
> unnecessary to include socket stuff.
Maybe so, but that's just the way it is. :-/
> if I have to compile someone else's library/program, I can't do it.
> never works for me, I always get errors I can't fix.
IIRC, it used to work with old old p7zip (circa 4.42 or such) port for
DJGPP. But yeah, it's buggy, so I didn't really recommend it directly.
> watt-32 doesn't have headers or libraries. the only thing in the bin
> dir is some .cfg files. it's useless.
> lotsa links and no go. the 32-bit protected mode link for stuff like
> watcom (djgpp not mentioned) leads to a german site (which I can't
> hardly read, but it appears to be a contact page.
> so that goes nowhere.
It works, you just have to compile it.
wget http://home.broadpark.no/~gvanem/watt32s-2.2-dev.10.zip
unzip watt32*.zip -d c:\watt32
c:
cd \watt32\src
set WATT_ROOT=c:\watt32
configur.bat djgpp
make -f djgpp.mak
cd ..\lib
dir *.a
(ignore the warnings, wait a few minutes, voila! c:\watt32\lib
\libwatt.a)
> installed ls80 and all other libraries in DJGPP and gort this:
>
> In file included from pthreads.cpp:1:0:
> c:/djc462~1/include/pthread.h:115:53: fatal error: sys/wtime.h: No
> such file or directory (ENOENT)
>
> that header is not #included in the source file, so it is somewhere
> within pthreads.h
I have no idea, libsocket is old and maybe doesn't work too well in
all cases. I only mentioned it for completeness. Don't use it. Use one
of the others.
> so I guess pthreads are officially dead on djgpp?
No, they're undead (as I don't think they were ever barely working or
supported anyways!). ;-)
> by the way, -pthreads switch gives an error in DJGPP and it should
> not.
Blame DJ. ;-) j/k
> > > Sun 12/25/2011 22:05:23.65|C:\prj\test\djgpp|>
>
> > > source code is an example from https://computing.llnl.gov/tutorials/pthreads/#Abstract
>
> > Okay, but you're asking for complications which I can't help with. I'm
> > don't grok multi-threading, sorry. It's a minefield.
>
> as long as you know a few simple concepts, then you are safe with some
> basic threading concepts.
(joking)
1). If you think you need them, you don't.
2). It's tricky even for enlightened people, so don't waste your time.
3). Turbo Boost (tm) is your friend.
4). Be patient. Single-threaded isn't so bad. ;-)
> >http://www.gnu.org/software/pth/
>
> thanks, I was looking elsewhere for documentation... I thought pth
> meant pthreads because they couldn't fit it into an 8.3 filename.
Nope, apparently it's a portable library, e.g. used by GM2 (GNU
Modula-2) for coroutines.
> > You may have better luck trying FSU Pthreads (see p7zip 9.13) and/or
> > the examples bundled with the Minix version of FSU (used with
> > permission):
>
> you're sure p7zip isn't simply 7-zip?
It's the POSIX port of 7-Zip, aka p7zip. Like I mentioned before,
DJGPP is kinda a weird hybrid, not fully Windows-style but not fully
POSIX. So while in theory we could have a native port of 7-Zip (at
least the cmdline version), in practice we don't, hence we're (badly)
piggybacking atop POSIX. (Win32's 7ZA.EXE still works with Japheth's
HX, I presume. At least it used to.)
> why is it zipped instead of a self-extracting exe? :-/
Because everybody already has ZIP and UNZIP. Besides, .tar or .shar
aren't very friendly (esp. to DOS).
> when you have to find unzip to extract an archiver that's pretty sad...
.ZIP isn't exactly rare. See here:
ftp://ftp.info-zip.org/pub/infozip/msdos/unz600x3.exe
Actually, see here:
http://www.freedos.org/software/?prog=unzip
> needs an sfx.bin file for dos for making self-extracting exe's.
It has one but it's QUITE large!! Better to not mess with it (or just
bundle the 7zdecode .EXE, available separately, much much smaller).
> maybe I can get 7-zip to come out with an official commandline dos
> version by putting in a sourceforge.net feature request.
I doubt it. Plus he seems to have slowed down a lot lately.
> >http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/file/7zi...
>
> >http://minix1.woodhull.com/pub/contrib/champoll.txt
> >http://minix1.woodhull.com/pub/contrib/champoll.tar.Z
>
> I am about to try, but I can usually only work with stuff that is
> precompiled... I can't compile unix stuff.
> I must be the only software engineer who can't compile unix stuff.
Yes, do try FSU Pthreads, it has a makefile, it worked building last
time I tried, but I never fooled with it much. It has to work somewhat
as p7zip seems to (mostly) work with it (and no socket lib needed).
Then try the (not really Minix) examples. And yes, *nix stuff is often
hard to compile, but I can't help that.
- Raw text -