NeXT Computers Forum Index NeXT Computers
www.NeXTComputers.org
 
Log in to check your private messagesLog in to check your private messages

Log inLog in  RegisterRegister


Profile  Search  Memberlist  FAQ  Usergroups
Taking the NeXT step (mach kernel upgrades)
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next
 
Post new topic   Reply to topic    NeXT Computers Forum Index -> Porting New Software
View previous topic :: View next topic  
Author Message
neozeed



Joined: 15 Apr 2006
Posts: 606
Location: Hong Kong

PostPosted: Wed May 17, 2017 6:30 pm    Post subject: Reply with quote

t-rexky wrote:
That's pretty awesome neozeed. I still cannot believe that there is this much breakage with the UFS. I understand going from the ancient BSD4.2 UFS with 2GB limit to something newer, but it seems that each iteration of the OS was breaking file system compatibility with the preceding versions. Maybe they were tweaking it to get a more "Mac like" UFS, before they threw in the towel and settled on HFS+?


It could be. I thought my toolchain was broken as the new boot programs didn't work... I tried my test disk, and I'm not getting file not found errors.

I guess this is also why the DR2 install is full of "this is not an upgrade" style messages in the setup. I haven't tried DR1 but I'm guessing it's filesystem is different in slight ways too.

It's been a long time since I ran OS X 1.0 and I don't think Qemu can run it at the moment... But I think the UFS was needed and capped at 8GB. I need to install 10.1 on pearpc, and see how big UFS can go. I just remember after 10.2 I used HFS+ onward from there.
_________________
# include <wittycomment.h>
Back to top
View user's profile Send private message Visit poster's website
neozeed



Joined: 15 Apr 2006
Posts: 606
Location: Hong Kong

PostPosted: Thu May 18, 2017 10:24 pm    Post subject: Reply with quote

It occurred to me that it's possible to run NeXTSTEP's userland chroot'd under Rhapsody. So I took one step further, and added a shell in the /etc/rc so the system would mostly boot up, but not start anything graphical yet.

I then restored a backup of a virgin NeXTSTEP install chroot'd to it, and ran something like:

Code:
/usr/sbin/chroot /nextstep bin/sh
cd /usr/lib/NextStep
./WindowServer & loginwindow


And I get the login window!



HOWEVER... it won't let me login. Mad

Code:
rhapsody:28# /usr/sbin/chroot /nextstep bin/sh
# cc -v
Reading specs from /lib/i386/specs
NeXT Computer, Inc. version cc-437.2.6, gcc version 2.5.8
# hostinfo
Mach kernel version:
         Kernel Release 5.3:
Sat Apr 22 14:20:09 SGT 2017; root(rcbuilder):kernel/BUILD/RELEASE_I386
Copyright (c) 1988-1995,1997-1999 Apple Computer, Inc. All Rights Reserved.


Kernel configured for a single processor only.
1 processor is physically available.
Processor type: I386 (Intel 586)
Processor active: 0
Primary memory available: 825.00 megabytes.
Default processor set: 36 tasks, 79 threads, 1 processors
Load average: 1.29, Mach factor: 0.22
#


It's not much, but at least I can run userland stuff....

It also occurred to me, that we really don't need the NeXTSTEP login, if we just run commands via -NXHost...



Just enable remote connections, IE insecure mode in preferences



Code:
chroot /nextstep /NextApps/Terminal.app/Terminal -NXHost rhapsody

_________________
# include <wittycomment.h>
Back to top
View user's profile Send private message Visit poster's website
NCommander



Joined: 11 Mar 2017
Posts: 29
Location: New York, NY

PostPosted: Wed May 24, 2017 5:20 pm    Post subject: Reply with quote

So I'm actually still alive. We're getting close to a release date at work and free time has evaporated into non-existence.

I'm happy to see neozeed took up the torch I left though I really wish I put the code up on github for him so he wouldn't have had to reproduce the wheel to get as far as I did (you could have PMed me Smile). It also looks like the missing drivers showned up to get around my hacks in DriverKit to allow the OS4.2 ones to load (at least HDD/CD).

Based on my earlier tests, it *is* possible to build almost all the packages we do have if you can sort the CoreOsMakefiles situation. I was able to get most of the base utilities to build.

Login failure is likely due to NetInfo taking a **** in a chroot. There's some serious deep magic on how NetInfo ties into the boot system which I remember back in Mac OS X 1.0. Its at least theorically possible to disable NI and get fallback behavior to /etc/* (this was doable in Mac OS X 10.0), and what's used in single user boot. You might want to try dumping out the NI database with nidump and putting the stuff in (/private)/etc/{passwd,group} and see if that let's things go.

EDIT: Reading the backscroll, you MIGHT want to try going with VirtualBox over QEMU. I had better luck with EIDE behaving under it. VBox has fairly decent logging so I might be able to pin down the crash if I can get a crash log or at least know how the converation goes.

As for mkfs and friends, the "right" way to do this is we need to rebuild the base system with the NeXTstep/OpenSTEP paths, and them slipstream them into the original installation media. That should create an installable OPENSTEP 4.2 + new voodoo. NeXT's install system is essentially a giant shell script (in /etc/rc.installer I think on the CD), and it shells out fdisk/mkfs/friends. It *might* be easier to get the hot mess to run on HFS+ if Darwin 0.3 has the missing "hfs_mountroot" function. That way we can get away from the UFS madness.
Back to top
View user's profile Send private message
neozeed



Joined: 15 Apr 2006
Posts: 606
Location: Hong Kong

PostPosted: Wed May 24, 2017 7:14 pm    Post subject: Reply with quote

NCommander wrote:
So I'm actually still alive. We're getting close to a release date at work and free time has evaporated into non-existence.

I'm happy to see neozeed took up the torch I left though I really wish I put the code up on github for him so he wouldn't have had to reproduce the wheel to get as far as I did (you could have PMed me Smile). It also looks like the missing drivers showned up to get around my hacks in DriverKit to allow the OS4.2 ones to load (at least HDD/CD).

Based on my earlier tests, it *is* possible to build almost all the packages we do have if you can sort the CoreOsMakefiles situation. I was able to get most of the base utilities to build.

Login failure is likely due to NetInfo taking a **** in a chroot. There's some serious deep magic on how NetInfo ties into the boot system which I remember back in Mac OS X 1.0. Its at least theorically possible to disable NI and get fallback behavior to /etc/* (this was doable in Mac OS X 10.0), and what's used in single user boot. You might want to try dumping out the NI database with nidump and putting the stuff in (/private)/etc/{passwd,group} and see if that let's things go.

EDIT: Reading the backscroll, you MIGHT want to try going with VirtualBox over QEMU. I had better luck with EIDE behaving under it. VBox has fairly decent logging so I might be able to pin down the crash if I can get a crash log or at least know how the converation goes.

As for mkfs and friends, the "right" way to do this is we need to rebuild the base system with the NeXTstep/OpenSTEP paths, and them slipstream them into the original installation media. That should create an installable OPENSTEP 4.2 + new voodoo. NeXT's install system is essentially a giant shell script (in /etc/rc.installer I think on the CD), and it shells out fdisk/mkfs/friends. It *might* be easier to get the hot mess to run on HFS+ if Darwin 0.3 has the missing "hfs_mountroot" function. That way we can get away from the UFS madness.


Hey glad u are alive... I didn't think a PM would reach you so I didn't try... I've been dragged down writing c# rest code and all around hating life.

Code:
4.4 BSD (darwin) (ttyp0)

login: root
[darwin:~] root# uptime
 6:59PM  up 22 days, 20:11, 2 users, load averages: 1.92, 1.54, 1.28
[darwin:~] root# uname -a
Rhapsody darwin 5.5 Kernel Release 5.5: Sun Apr 30 10:53:53 SGT 2017; root(rcbuilder):kernel-7/BUILD/RELEASE_I386 Copyright (c) 1988-1995,1997-1999 Apple Computer, Inc. All Rights Reserved.  i386


This is the Darwin 0.3 I changed the string back to Rhapsody as it was wrecking havoc with any 3rd party auto-detect as they all want a Darwin 5 or something...

I've been trying to figure out how they made the OS & devkit distribution CD's but I came up with nothing. Maybe it was a tool that did a dump of a filesystem but output to a special 2k sector UFS? I really don't know.

I've gotten the new boot programs to work on a new filesystem just fine, so slipstreaming on an install CD would certainly be best. I was going to try to use my chroot'd NeXTSTEP/OPENSTEP to try to build disk_commands, but didn't get around to it.

The EIDE driver is a freaking nested mess from hell. Like I mentioned the only thing I could figure out is that, yes it does lose interrupts, and with a bit more messing around it looks like sometimes it tries to do reads that are just too big.

It's super painful for me to do floppies in real life, as I only have one working diskette, but I have a physical machine I got to run Rhapsody. When I tried to run NeXTSTEP on it, the EIDE controller went crazy. However I bought a new (lol) disk that let's me jumper it down to 2GB, and Rhapsody installed fine. I would have to re-install but I have a suspicion that it may not be the controller / driver code exactly failing but some capability on the newer disks that is freaking it out.

Also running some NS/OS programs give me a syscall missing error.... so it may not just cleanly run, I have to re-build a kernel to at least tell me what syscall # it tried to run. Running GDB ch-rooted is kinda useless, it runs but errors on some weird ioctl on the tty.

I'm just an amateur in this stuff, however I think enough time and with (LOTS) of help we can certainly get this thing going again! I've also started to look at updating the bsd directory from Darwin 1.0 vs Darwin 0.3 and it doesn't look like a tremendous amount of drift, some fixes here & there in the filesystem but they did add about 10 new memory syscalls.

I also don't want to get anyone all crazy excited about 68k, but I did find the source to Mach 2.5 on CD #4 of the CSRG set.

mach25 & mach25-i386. Yes there is both SUN-3 & i386 stuff in there. It may be also possible to de-evolve Darwin back to an earlier BSD compatibility level? Kornbluth?

It may not be too much at the moment, but it's nice having an 8GB root disk. And seamlessly going up to 825MB of RAM.
_________________
# include <wittycomment.h>
Back to top
View user's profile Send private message Visit poster's website
NCommander



Joined: 11 Mar 2017
Posts: 29
Location: New York, NY

PostPosted: Wed May 24, 2017 8:30 pm    Post subject: Reply with quote

Wait, greater than 8 GiB?

Is the physical drive larger? It might be having a heart attack due to LBA. That's a problem on Xenix due to the fact it only supports CHS. The ATA controller coughs up a response and interrupts it didn't know how to handle and it shat a rather large brick because of it.

For the time era that we're talking about, larger drives would have been always universally SCSI which has a more sane history attached to it. If the EIDE driver was completely shot, then we should be similar issues when reading from the CD interface (which is ATAPI granted, but thats ATA with extensions).

I need to look at my DriverKit code to see how I solved this issue, but I think I was using the OS4.2 driver with patches to DriverKit to implement changed ABI calls.

EDIT: I'm not seeing the EIDE driver source. I can't easily pull out the VM images here to check what I did but you ultimately got further than I did. The base memory check in the kernel is controlled by boot1 in libsa. You could get DR2 to boot to 512 by using OpenStep's boot sector.
Back to top
View user's profile Send private message
neozeed



Joined: 15 Apr 2006
Posts: 606
Location: Hong Kong

PostPosted: Wed May 24, 2017 9:06 pm    Post subject: Reply with quote

NCommander wrote:
Wait, greater than 8 GiB?

Is the physical drive larger? It might be having a heart attack due to LBA. That's a problem on Xenix due to the fact it only supports CHS. The ATA controller coughs up a response and interrupts it didn't know how to handle and it shat a rather large brick because of it.

For the time era that we're talking about, larger drives would have been always universally SCSI which has a more sane history attached to it. If the EIDE driver was completely shot, then we should be similar issues when reading from the CD interface (which is ATAPI granted, but thats ATA with extensions).

I need to look at my DriverKit code to see how I solved this issue, but I think I was using the OS4.2 driver with patches to DriverKit to implement changed ABI calls.

EDIT: I'm not seeing the EIDE driver source. I can't easily pull out the VM images here to check what I did but you ultimately got further than I did. The base memory check in the kernel is controlled by boot1 in libsa. You could get DR2 to boot to 512 by using OpenStep's boot sector.


I'm just at 8GB, although I know that diskinit command tries to live in bios bootable space (8GB according to the source) I should try a larger one....

It may be QEMU I don't know.

Code:
disk -u -i /dev/rhd1h


8GB although I made a 10GB qcow. Obviously you need to run this from the source version of diskdev-cmds-1 ...
_________________
# include <wittycomment.h>
Back to top
View user's profile Send private message Visit poster's website
NCommander



Joined: 11 Mar 2017
Posts: 29
Location: New York, NY

PostPosted: Wed May 24, 2017 9:25 pm    Post subject: Reply with quote

Well, the boot structure and early IDE initialization lives in boot0. The processor is basically kicked into Protected Mode, and then it does a lot of the magic to make xnu happy. That's why there's supririsngly little initialization code in machdep places since it all happens in early boot. Also a distinct lack of commenting.

How exactly are you seeing EIDE errors? Divining your debugging from the earlier posts isn't going well for me. We should probably get a canonical repo on github. I can't promise a lot of time on my part to work on this but I always intended to get back to it. My thought here is the "right" thing to do is try and build all the Darwin 0.1/0.3 sources into a bootable system, then glue on the userland there. If we can get that to boot more or less standalone, we're golden.

Annoyingly, I can't get boot0 to compile. As far as I can tell, I *have* all the bits to it, its just got a stupid number of hard dependencies on header files and compiler magic that weren't on OS4.2, and I'm not convinced are there on DR2. NeXT (and Apple) didn't ship the private header files required for most of this (this made my first few attempts at building driverkit a sad panada).

There's a jump table in the kernel of bootable root filesystems. THe kernel knows how to boot from UFS, and FFS2-style filesystems. There's support for HFS, but the mountroot function is ENOTIMPLEMENTED. Looking at the UFS one though, it looks really simple to implement so part of me is wondering if the correct way to move forward is to dump teh UFS madness

I do vaguely remember however that early Mac OS X Server's required a UFS boot partition; it was listed in Disk Setup of the eras (Mac OS X Server (Boot)/Mac OS X Server (Root)).

EDIT: Brainwave here. It MIGHT be possible to convince the entire system to build from Mac OS X Server. On Darwin, it was possible to build a FAT build of the entire operating system and there's shims in place to set the arch flags. Biggest headache is we're stuck with the Rhaspody filesystem layout, but that might be fixable.

SON OF EDIT: Saw your posts with the 0x20 command error; that's ATA READ SECTORS and it looks like we're stuck in PIO mode. PIO is basically data in/out through the the command registers of the ATA interface. It "works" but is slow as dog feces in winter. Looking at how the driver initialization works, it looks like it always tries to put the drive in fast timing mode for PIO unless doing DMA ...

I'm going to have to get a debugger out and trace the ATA blowup to figure out WTF this is actually trying to do.


Last edited by NCommander on Wed May 24, 2017 10:06 pm; edited 1 time in total
Back to top
View user's profile Send private message
neozeed



Joined: 15 Apr 2006
Posts: 606
Location: Hong Kong

PostPosted: Wed May 24, 2017 10:06 pm    Post subject: Reply with quote

boot0 compiles fine..... You need to jump up to Rhapsody to start the adventure though, OPENSTEP is.. too old. And I think some of the key headers & whatnot is missing..

Code:
make OBJROOT=/tmp/boot-2/obj SYMROOT=/tmp/boot-2/sym DSTROOT=/tmp/boot-2/roo RC_ARCHS=i386


which gets me:

Code:
rhapsody:14# ls /tmp/boot-2/sym/i386/
boot       boot1      libsa.a    nasm*      ndisasm.1  sarld.sys*
boot.sys*  boot1f     libsaio.a  nasm.1     nullboot1  vers.h
boot0      librcz.a   machOconv* ndisasm*   sarld*


I use qemu as I can futz with devices on the otherside, although other than making an IDE controller that sits in the same place as a parallel port, I haven't done anything... .sigh. Plus it was crazy easy to convert my qcow into a vmdk so I could put my Darwin install on my VMWare ESXi server.

Anyways most of the project directories have a dpkg/control file that has dependencies listed. Of course what is 'build-base' ... some debian alias that I haven't spent time trying to find what is what, but ..... yeah as always once the weird dance of doing a make world is figured out it wont be so bad for building a system.

Code:
rhapsody:20# cc -v
Reading specs from /usr/libexec/i386/2.7.2.1/specs
Apple Computer, Inc. version cc-771.4, based on gcc version 2.7.2.1


On my qemu image I put on sourceforge it's missing some bits to actually compile some stuff, I was pissed as the dpkg thing actually did a rm -rf DSTROOT for me.... so I took a backup and uploaded it. I was so mad that day.
_________________
# include <wittycomment.h>
Back to top
View user's profile Send private message Visit poster's website
NCommander



Joined: 11 Mar 2017
Posts: 29
Location: New York, NY

PostPosted: Wed May 24, 2017 10:21 pm    Post subject: Reply with quote

If memory serves, I think build-base is a meta-package. Poking the Darwin 0.3 sources. The super makefile is there (buildtools). You should theorically be able to setup everything in the right places, push the button and get stuff out.

I may need to go see if I can host a VM somewhere so I can try to kick off a build.
Back to top
View user's profile Send private message
NCommander



Joined: 11 Mar 2017
Posts: 29
Location: New York, NY

PostPosted: Thu May 25, 2017 10:59 am    Post subject: Reply with quote

neozeed got me setup on a build image so we can try and collobrate on this. Right now, it looks like the fundamental problem is there's some incompatibilities between Darwin 0.3 and DR2 with shared library handling which is why so many things are pooping the bed.

I also found that the image works somewhat smoother on VirtualBox (sans networking). I'm currently seeing if I can get the toolchain to build successfully so I can build Perl and kick off a master build
Back to top
View user's profile Send private message
neozeed



Joined: 15 Apr 2006
Posts: 606
Location: Hong Kong

PostPosted: Thu May 25, 2017 12:16 pm    Post subject: Reply with quote

Do you think the perl from OS X Server 1.0 may build better, as it's Rhapsody and should be fine with -DNEXT and friends vs the shift to Darwin?

perl-5.6.0-13.tar.gz

I'm copying this one over now... If I was smart I'd have put it on the source CD. Embarassed
_________________
# include <wittycomment.h>
Back to top
View user's profile Send private message Visit poster's website
neozeed



Joined: 15 Apr 2006
Posts: 606
Location: Hong Kong

PostPosted: Thu May 25, 2017 1:21 pm    Post subject: Reply with quote

SOoo... I got the OS X Server perl to build.

As you know they were in some weird process of purging NEXT from OS X. And so many of the NX* headers are missing or just in really weird places. As a quick stop-gap I did this:

Code:
    55  13:08   mkdir /usr/local/include
    56  13:08   mkdir /usr/local/include/objc
    57  13:08   cp /usr/src/build/Libc-1/internat.subproj/NX*h /usr/local/include/objc
    60  13:09   make OBJROOT=/tmp/perl-1/obj SYMROOT=/tmp/perl-1/sym DSTROOT=/tmp/perl-1/roo RC_ARCHS=i386


And miniperl built


Code:
qemuvm:67# /tmp/perl-1/obj/miniperl -version

This is perl, version 5.004_01

Copyright 1987-1997, Larry Wall


I had to enable DNS to let me wget the OS X Server 1.0 files from staticky.com, and had to reboot. I thought I could mount my NFS through my VPN but... I'm sure the latency is insane, or I'm too impatient or both.

I get the impression that lots of stuff gets hidden in the private parts of the /System framework, or is brushed aside in some weird manner, like the internal build stuff is OK being all NEXT, but what is shared out is not. Then again this is such a rough spot of transition, politically and all that.

Sorry about the reboot...



*--** edit

One last update, in the circular dependencies from hell. I tried the perl from Darwin 0.3 and there is a missing function, _environ from libc....


Code:
cc -dynamiclib \
      -compatibility_version 1 \
      -current_version ${dylib_version} \
      -image_base ${base_address} \
      -install_name ${framework_path}/Perl \
      -o Perl \
      perl.o  gv.o toke.o perly.o op.o regcomp.o dump.o util.o mg.o byterun.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o taint.o deb.o universal.o globals.o perlio.o
DYLD_LIBRARY_PATH=/private/tmp/perl-2/obj/Perl:/tmp/perl-2/obj cc  -arch i386  -o miniperl miniperlmain.o Perl
DYLD_LIBRARY_PATH=/private/tmp/perl-2/obj/Perl:/tmp/perl-2/obj ./miniperl -w -Ilib -MExporter -e 0 || make minitest
dyld: ./miniperl Undefined symbols:
__environ
rm -f lib/re.pm
cat ext/re/re.pm > lib/re.pm
You may see some irrelevant test failures if you have been unable
to build lib/Config.pm.
cd t && (rm -f perl; /bin/ln -s ../miniperl perl) \
        && DYLD_LIBRARY_PATH=/private/tmp/perl-2/obj/Perl:/tmp/perl-2/obj ./perl TEST base/*.t comp/*.t cmd/*.t io/*.t op/*.t pragma/*.t </dev/tty
dyld: ./perl Undefined symbols:
__environ
make[2]: [minitest] Error 67 (ignored)
DYLD_LIBRARY_PATH=/private/tmp/perl-2/obj/Perl:/tmp/perl-2/obj ./miniperl configpm tmp
dyld: ./miniperl Undefined symbols:
__environ
make[1]: *** [lib/Config.pm] Error 67
make: *** [build] Error 2



Which is in perl.c

Code:
#if defined(__NeXT__) && defined(__DYNAMIC__)
    _dyld_lookup_and_bind
        ("__environ", (unsigned long *) &environ_pointer, NULL);
#endif /* environ */


So being me, I changed __environ to _environ and it's compiling!!.. further.


Code:
        Making Errno (nonxs)
Writing Makefile for Errno
mkdir ../../lib/auto/Errno
mkdir blib
mkdir blib/man3
../../miniperl -I../../lib -I../../lib -I../../lib -I../../lib Errno_pm.PL
errno.c:2: illegal external declaration, found `ENOSYS'
cp Errno.pm ../../lib/Errno.pm
Manifying blib/man3/Errno.3
dyld: perl Undefined symbols:
_Perl_Sv
_Perl_markstack_ptr
_Perl_na
_Perl_stack_base
_Perl_stack_sp
_Perl_sv_yes
_do_undump
_perl_destruct_level

        Everything is up to date. 'make test' to run test suite.

_________________
# include <wittycomment.h>
Back to top
View user's profile Send private message Visit poster's website
NCommander



Joined: 11 Mar 2017
Posts: 29
Location: New York, NY

PostPosted: Thu May 25, 2017 1:57 pm    Post subject: Reply with quote

That's what happened when I tried the Darwin 0.3 Perl.

THe header paths are very strange. A lot of stuff stuff install Frameworks, but only install in the B directory but don't make the Current link.
Back to top
View user's profile Send private message
neozeed



Joined: 15 Apr 2006
Posts: 606
Location: Hong Kong

PostPosted: Thu May 25, 2017 7:37 pm    Post subject: Reply with quote

I think the fundamental problem is even with Rhapsody-DR2 there has simply been too much drift in the versions.

I downloaded my 0.3 build thing, and this time I got perl to build. I'll build some more stuff manually as this is looking somewhat better, then build an 8GB disk, and put that online... I don't think you need or care for the Rhapsody stuff on top? I could do an overlay but I don't think its needed.


Also what is the best way to install manually built stuff?

I know that setting DSTROOT=/ is... dangerous as these scripts tend to do stupid shit like rm -rf DSTROOT..

Rolling Eyes

cp -R DSTROOT /

?
_________________
# include <wittycomment.h>
Back to top
View user's profile Send private message Visit poster's website
neozeed



Joined: 15 Apr 2006
Posts: 606
Location: Hong Kong

PostPosted: Thu May 25, 2017 8:41 pm    Post subject: Reply with quote

ugh anyone have PDO?

Code:
/usr/bin/cc -arch i386 -O  -Wmost  -g  -fno-common -I/build/objc4-1/sym/objc4.build/ProjectHeaders -I -I -I/build/objc4-1/sym/objc4.build/derived_src/runtime -I. -pipe       -I/build/objc4-1/sym -I/build/objc4-1/sym/objc4.build/Headers -I/build/objc4-1/sym/objc4.build/PrivateHeaders -F/build/objc4-1/sym    -Wno-unused -DNSBUILDINGOBJC -I/build/objc4-1/sym  -ObjC       -c -o /build/objc4-1/obj/objects-optimized/runtime/objc-file.i386.o objc-file.m
In file included from objc-file.m:29:
objc-file-generic.m:29: pdo.h: No such file or directory
In file included from objc-file.m:29:


I don't have any pdo.h anywhere. Embarassed

I know it was sold as an addon, I have EOF somewhere, but I don't think PDO was sold with EOF, I think it was it's own thing.
_________________
# include <wittycomment.h>
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    NeXT Computers Forum Index -> Porting New Software All times are GMT - 7 Hours
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8  Next
Page 7 of 8

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum



Powered by phpBB © 2017 phpBB Group