issue with shell/pdksh in current (10 alpha 4)

Hi,

I'm working in a PR about pdksh in current,
and I'm not really able to figure out what's
going on. So that's the facts :

A breakage was reported in august about pdksh
in current (ports/181438). The PR says pdksh
hangs after the first command was sent ( run
pdks, type 'ls' validate and you are locked)

After a lookup on the code and a little debug
I found that, in current, after the main process
fork to perform the 'ls', the child fall in a zombi
state and the father remains waiting for the
SIGCHLD signal forever.
Of course, in 9-STABLE things works fine.

I try to use a pdksh build in 9 in current,
and things works fine. I start thinking the
problem commes from clang. Before any change
I test GCC in current,and bang! dosn't works.

Here is a little array explaining my tests.

Environments:

10.32 : FreeBSD 10 Alpha 4 x32
10.64 : FreeBSD 10 Alpha 4 AMD64
 9.32 : FreeBSD 9-STABLE   x32
 9.64 : FreeBSD 9-STABLE   AMD64


build / run in| 10.32 | 10.64 |  9.32 |  9.64 |
----------------------------------------------
Build w/CLANG |KO     |KO     | Not tested
in native env |v3.3   |v3.3   |
----------------------------------------------
Build w/GCC   |KO     |KO     |all OK
in native env |v4.6.3 |v4.2.1 |v4.2.1
----------------------------------------------
Build w/GCC   |OK     |OK     |all KO(Build in 10)
in 9-STABLE 32|v4.2.1 |v4.2.1 |v4.6.3
----------------------------------------------

So....
If I use a pdks build in its own environement
with clang or gcc, pdksh fail.
The same tes done in 9 success.

If I copy 9-STABLE pdksh builds to 10, the imported
pdksh works fine.
If I copy the 10 pdksh builds to 9, pdksh dosn't works.

It seems the problem is related to the build environement
in current, without regads to the copiler used.
Maybe a macro failure......

Anyone has a clue ?

Best regards,
- rodrigo