Euphoria Ticket #596: euc bug on Mac OS X

Hello All, when attempting to create a DLL with euc on Mac OS X, it often fails with an error stating:

error: only weak aliases are supported in this configuration

Come to find out, that the way that we define function names for export, is the cause of the issue.

An example:

int preprocess() attribute ((alias ("_1preprocess")));

This will cause the error to occur, but if we use:

int preprocess() attribute ((weak, alias ("_1preprocess")));

This will allow the library to be built, but it will still cause an error, as evidently, the weak alias of the function, is still zero, instead of a valid pointer to _1preprocess.

This needs to be looked into.

Details

Type: Bug Report Severity: Major Category: Translator
Assigned To: unknown Status: Fixed Reported Release: 4.0.0
Fixed in SVN #: View VCS: none Milestone: 4.0.1

1. Comment by jimcbrown Jan 26, 2011

This looks rather complex.

http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html

So an alias has to be in the same translation unit, or else it's an error, unless it's a weak alias.

But weakref (which seems to be the same thing as a weak alias iiuc) is only supported for static functions.

2. Comment by mattlewis Jan 26, 2011

I guess OSX falls under "Not all target machines support this attribute."

Which means, I suppose, no nice exported function names for OSX.

3. Comment by jimcbrown Jan 26, 2011

I know this is a stupid question, and that if it were possible it would have been done already, but I still just have to ask:

Why can't we replace

int preprocess() attribute ((weak, alias ("_1preprocess"))); 

with

extern int preprocess(); int preprocess() { return _1preprocess(); } 

4. Comment by mattlewis Jan 26, 2011

I suppose we can do that, at least on OSX.

5. Comment by SDPringle Mar 20, 2011

Following Jim's suggestion we should also put arguments for the wrapper function as well? This adds a little more than a one liner. Another couple of loops for parameters of the wrapper and the call of the function itself. I suspect there is a cleaner solution to this problem.

6. Comment by SDPringle Mar 20, 2011

Fixed but not tested in change set 665d1c638611.

7. Comment by eumario Mar 28, 2011

Confirmed, DLL's are now built, and properly opened with open_dll(). Thank you SDPringle.

Search



Quick Links

User menu

Not signed in.

Misc Menu